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THEME 


Recent  AGARD  activities  have  indicated  a  strong  need  for  more  efficient  avionics  system  engineering.  There  is  a 
growing  need  for  reducing  development  time,  effecting  savings  in  costs  of  ownership,  and  in  extending  the  life-time  of 
avionics  systems.  This  must  be  accomplished  along  with  meeting  needs  of  the  user  faced  with  a  growing  threat.  With  the 
growing  complexity  of  avionics  systems  (as  well  as  other  systems),  it  is  important  to  develop  and  maintain  expertise  in  system 
planning,  architecture,  and  management. 

This  Lecture  Series  addresses  the  important  systems  engineering  aspects  of  Requirements,  Systems  Integration. 
Prototyping,  and  Design.  In  addition,  the  impact  of  technology  on  system  architecture  will  he  discussed  Methodologies  arc 
described  and  actual  case  histories  will  serve  as  practical  examples  of  modern  system  engineering. 

This  Lecture  Series,  sponsored  by  the  Avionics  Panel  of  AGARD.  has  been  implemented  by  the  Consultant  and 
Exchange  Programme. 


Le  besoin  de  rendre  plus  performant  Tingenierie  dcs  systemes  avioniques  ressort  ties  nettement  dcs  activites  recentes 
de  I'AGARD.  II  devient  de  plus  en  plus  neccssaire  d  ccourter  les  delais  de  developpement,  dc  realiser  dcs  economics  dans 
lex  coins  globaux  et  de  prolonger  la  duree  dc  vie  dcs  systemes  avioniques.  tout  en  repondant  aux  exigences  dc  1'utihsatcur 
face  a  la  menace  grandissante. 

Vu  la  nature  dc  plus  en  plus  complexe  dcs  systemes  avioniques  (et  d'autres  systemes)  il  importe  de  developper  et  dc 
maintenir  I'cxpertisc  existame  dans  1c  domaine  de  la  planification.  ('architecture  et  le  management  dcs  systemes. 

Ce  Cycle  de  Conferences  examine  les  aspects  importants  de  Tingenierie  de  systemes  en  maticre  dc  besoins. 
^'integration  dcs  systemes,  de  realisation  de  prototypes,  et  de  conception.  En  outre.  Timpact  de  la  technologic  xur 
Tarchitccture  dcs  systemes.  est  aussi  examine.  Des  descriptions  dc  differentes  methodologies  sont  presentees  ct  dcs  cas  reels 
sont  utilises  a  titre  d'cxcmples  pratiques  d'ingenierie  dc  systemes  modernes. 

Cc  Cycle  dc  Conferences  est  presente  dans  le  cadre  du  programme  dcs  Consultants  ct  dcs  cchangex.  sous  I'cgide  du 
Panel  AGARD  d'Avioniquc. 
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AVIONICS  SYSTEM  ENGINEEKING — AN  INTRODUCTION 


Dr  Fred  I.  Diamond 
Rome  Air  Development  Center 
Griffiss  AFB  NY  13441-5700  USA 


Summary 

System  engineering  is  the  process  used  in  the  evolution  of  systems  from 
identification  of  a  need  through  construction  and/or  production  and  deployment 
in  an  operational  environment.  It  is  a  process  that  involves  the  application 
of  appropriate  scientific  and  technical  knowledge  (1)  to  transform  an 
operational  need  into  a  system  configuration  with  defined  parameters,  through 
an  iterative  process  of  analysis,  design,  test,  and  evaluation?  (2)  to 
integrate  all  performance  requirements,  including  reliability,  maintainability, 
supportability ,  etc.  into  the  total  engineering  effort;  and  (3)  to  integrate 
related  components  to  insure  interoperability  and  optimum  system  performance. 

It  is  a  process  that  also  considers  economic  factors  such  development  and  life 
cycle  costs. 

The  life  cycle  process  involves  several  key  steps,  many  iterative,  but  in  an 
orderly  and  controlled  manner.  They  include  Requirements,  Architecture 
Specification,  Design,  Development/Construction,  Test  &  Evaluation,  and 
Operational  Use. 

With  the  growing  complexity  of  avionics  systems,  effective  systems  engineering 
is  critical.  Therefore,  we  must  p;  t  greater  emphasis  on  architectures, 
subsystem  design  and  interfaces  and  r-ystem  integration.  Only  through  a  total 
systems  engineering  approach  from  the  very  initial  phases  of  the  system  life 
cycle  may  we  achieve  a  well-engineered  system.  The  payoff  will  be  reduced  cost 
of  ownership  and  greater  mission  effectiveness. 


Introduction 

A  growing  and  more  sophisticated  threat  plus  shrinking  budgets  are  placing 
even  more  challenges  to  the  R&D  community.  Faced  with  complaints  about 
lengthy  and  costly  developments,  rapid  obsolescence,  and  excessive  costs 
of  ownership,  we  have  all  heard  the  following  concerns: 

How  to  develop  timely  solutions  which  are  responsive  to  new  and 
changing  requirements. 

How  to  better  integrate  elements  into  new  or  existing  systems. 

How  to  integrate  hardware  and  software  functions. 

How  to  achieve  interoperabil ity . 

How  to  reduce  life  cycle  costs  and  make  systems  more  usable  and 
supportable. 

How  to  predict  system  cost  and  performance. 

How  to  accomplish  timely  and  non-disrupt ive  technology  insertion. 

How  to  plan  for  proper  test  and  evaluation. 

How  to  manage  large  programs. 

These  reflect  the  need  for  more  effective  system  engineering,  and  such  issues 
have  been  addressed  in  many  activities  of  AGARD's  Avionics  Panel. (1-71  With 
the  growing  complexity  of  avionics  systems,  system  engineering  is  critical. 
The  increased  use  of  automation  has  broadened  the  scope  of  avionics  system 
engineering.  A  recent  AGARD  study  of  avionics  identified  system  engineering 
as  one  of  the  more  pressing  problems  but  also,  an  opportunity  for  major 
improvements. C 8 1  Incidently,  system  engineering  is  a  major  problem  in  all 
development  and  acquisition  activities,  not  only  in  other  areas  of  Defense 
such  as  Command  and  Control,  bu.t  in  many  other  endeavors  of  our  society. 
Apparently,  as  the  need  arose,  we  developed  many  kinds  of  engineering 
specialists  in  all  of  the  conventional  engineering  areas  such  as  electrical 
and  electronic  engineering,  but  we  may  have  neglected  the  important  role 
of  the  system  engineer,  the  individual  who  has  the  skills,  breadth,  and 
experience  to  ensure  that  all  interacting  components  fit  into  an  efficient, 
cost-effective  entity. 


In  the  broadest  sense,  systems  may  not  be  the  same,  but  the  general  methods 
used  in  arriving  at  a  successful  system  are  similar.  This  is  the  function 
of  system  engineering,  which  should  be  considered  as  a  professional  activity 
and  an  academic  discipline.  Many  universities  are  now  offering  programs 
in  System  engineering,  and  many  books  address  this  subject. [9-11]  System 
Engineering  may  be  defined  as  the  process  used  in  the  evolution  of  a  system 
beginning  with  the  identification  of  a  need  and  ending  with  the  construction 
and/or  production  and  deployment  in  an  operational  environment.  It  is  a 
process  that  involves  the  application  of  appropriate  scientific  and  technical 
knowledge  (1)  to  transform  an  operational  need  into  a  system  configuration 
with  defined  parameters,  through  an  iterative  process  of  analysis,  design, 
test,  and  evaluation;  (2)  to  integrate  all  performance  requirements,  including 
reliability,  maintainability,  suppor tability ,  etc.  into  the  total  engineering 
effort;  and  (3)  to  integrate  related  components  to  insure  interoperabil i ty  and 
optimum  system  performance.  It  is  a  process  that  also  considers  economic  factor 
such  development  and  life  cycle  costs. 

The  life  cycle  process  involves  several  key  steps,  many  iterative,  but  in 
an  orderly  and  controlled  manner.  One  of  several  variations  includes 
Requirements,  Architecture,  Specification,  Design,  Development/Construction, 

Test  &  Evaluation,  and  Operational  Use.  The  lequirements  phase  is  the 
beyinning  step  in  the  transformation  of  operational  requirements  to  technical 
requirements.  It  includes  examination  of  "customer"  needs  and  concepts  of 
operations,  along  with  considerations  of  performance,  cost,  scheduling,  and 
reliability  and  maintainability.  It  extends  to  analysis  of  these  requirements 
for  the  formulation  of  system  functional  requirements.  The  Architecture 
phase  involves  system  concepts  and  synthesis.  Alternate  architectures  are 
defined  and  prototypes  are  described.  Hardware  and  software  aspects  are 
examined  along  with  subsystem  interfaces.  Modelling  and  mathematical 
representation  may  play  an  important  role  in  order  that  alternative  concepts 
and  architectures  may  be  examined  and  compared.  The  definition  of  the  system 
architecture  and  a  detailed  functional  analysis  leads  to  Specifications. 

Given,  for  example,  such  avionics  elements  such  as  sensors,  navigation, 
displays,  communications,  etc.,  one  may  describe  detailed  technical  speci¬ 
fications  and  interfaces  at  the  subsystem  and  component  level.  Relevant 
standards  are  also  identified,  along  with  appropriate  figures  of  merit  and 
measures  of  performance.  The  system  design  not  only  involves  subsystems  and 
components,  but  also  takes  into  account  the  interaction  and  interoperability  and 
integration  of  its  component  subsystems,  the  identification  of  critical  elements 
It  requires  decisions  regarding  the  use  of  off-the-shelf  elements  rather  than 
development.  It  must,  at  the  onset,  consider  hardware  and  software  as  an 
integral  design.  It  should  include  such  factors  as  life  cycle  costs,  logistics 
support  and  measures  of  effecti veness. 

A  good  example  is  Reliability  and  Maintainability.  The  system  design  must 
consider  not  only  individual  components  with  respect  to  specified  performance 
under  carefully  defined  environmental  conditions,  but  it  also  must  take 
into  account  overall  system  performance  and  design.  Decisions  regarding 
redundancy,  self-repair,  fault-tolerance,  graceful  degradation,  and 
reconfigurability  must  be  made.  For  example,  redundancy  can  be  practiced 
at  the  chip  level  or  at  the  subsystem  level.  We  may  wish  to  assign  a  function 
to  other  resources.  For  example,  if  a  computer  supporting  an  important 
function  fails,  one  might  wish  to  have  the  capability  to  replace  it  with 
a  similar  computer  performing  a  non-critical  or  low-priority  function  at 
that  particular  phase  of  a  mission.  And  new  technologies  such  as  active- 
phased  arrays  merit  consideration  of  cost-effectiveness  because  of  the 
graceful  degradation  they  provide.  Thus,  testability  and  maintainability  must 
be  part  of  the  design  process,  as  v/ell  as  the  extent  of,  the  usage,  and 
the  nature  of  modules,  for  easy  maintenance,  reduced  logistics  support, 
reconfigurability,  and  follow-on  modification  or  upgrading.  Proper  attention 
to  factors  such  as  these  early  in  the  life  cycle  will  avoid  problems  later; 
ignoring  them  may  be  very  costly. 

As  the  system  progresses  through  its  life  cycle,  engineering  decisions  are 
made  that  may  impact  on  earlier  design  decisions.  The  system  engineer  must 
be  sensitive  to  this;  otherwise,  adverse  effects,  directly  or  indirectly, 
sometimes  in  subtle  ways,  may  occur. 

Development/Constr uction  involves  not  only  satisfying  specifications  and 
standards.  It  must  consider  process  control,  quality  assurance,  testability 
and  cost.  Test  &  Evaluation  includes  preparation  of  an  appropriate  test 
plan,  specification  of  test  methodology  and  equipment,  calibration,  data 
reduction,  and  analysis. 

Each  of  the  steps  involves  analysis  and  simulation,  and  may  require  feedback 
and  iteration.  Such  analysis  may  involve  system  trade-offs  and  risk  assess¬ 
ment,  analysis  of  alternative  concepts  and  designs,  analysis  of  life  cycle 
costs  vs.  performance,  and  prediction  of  performance  under  different  scenarios. 


1-3 


System  engineering  of  aircraft  systems  is  particularly  challenging.  Aircraft 
systems  are  "super"  systems  whose  very  elements  (e.g.  avionics)  are  themselves 
complex  systems.  They  utili2e  a  diverse  collection  of  sophisticated  equipment 
for  sensing,  communications,  and  information  processing.  They  involve  the 
interaction  of  equipment  and  the  people  who  operate  and  maintain  them.  A 
major  design  challenge  is  the  integration  of  information  to  be  used  by  the 
pilot  who  must  perform  navigation,  flight  control,  fire  control,  etc., 
interacting  with  sensor  and  threat  data  through  displays,  observations, 
and  audio  inputs.  Furthermore,  new  technology  is  constantly  emerging — 
adaptive  signal  processing,  distributed  processing  and  data  bases,  artificial 
intelligence/expert  systems,  parallel  processing — and  these  must  be  considered 
in  the  context  of  system  performance  including  interoperability,  survivability, 
connectivity,  rapid  deployment,  and  reliability  and  maintainability.  The 
nature  of  this  very  rapid  progress  in  electronics,  electromagnetics,  and 
information  processing  is  creating  new  system  questions.  With  the  advent  of 
VLSI  and  VHSIC,  the  distinction  between  devices  and  circuits  is  vanishing; 
progress  in  monolithic  microwave  integrated  circuits  raises  similar  system  and 
sub-system  issues.  Microprocessor  developments  raise  new  questions  regarding 
the  trade-offs  between  hardware  and  software.  The  evolution  of  photonics  offers 
new  opportunities  and  challenges  for  system  design  and  integration.  These 
technical  trends  may  imply  the  need  for  and  utilization  of  more  specialists, 
but  future  avionics  developments  will  also  require  systems-or iented  engineers. 

By  definition,  a  system  is  any  collection  of  elements  that  interact  or 
interrelate.  With  more  sophisticated  and  more  interdisciplinary  technology, 

System  concepts  and  system  engineering  apply  even  at  the  microchip  level. 

System  engineering  should  be  of  concern  at  all  levels  of  engineering,  and 
involve  both  hardware  and  software.  The  need  for  a  system-oriented 
engineer  pervades  every  aspect  of  development  and  acquisition. 

For  example,  consider  the  antenna  engineer.  In  the  future,  the  antenna 
engineer,  must  be  such  a  systems-or iented  technologist.  The  use  of  radiating 
elements  on  the  same  substrate  with  monolithic  microwave  integrated  circuits 
and  their  coupling  to  processing  electronics  are  system  and  sub-systerr 
issues.  With  further  advances  in  high  speed  digital  processing  and  analog- 
to-digital  conversion,  the  prospect  of  all-digital  beam  forming,  scanning, 
and  processing  is  upon  us.  A  clear  distinction  between  transmitter,  receiver, 
antenna,  and  processor  may  no  longer  exist,  and  interrelations  among  many 
specialties  will  become  greater.  Electromagnetic  radiation  is  still  important, 
but  digital  beam  forming  and  adaptive  nulling  also  require  a  knowledge  of  modern 
control  theory  and  information  theory.  The  digital  manipulation  of  data, 
the  processing  of  signals,  and  the  generation  of  control  signals  require  skills 
in  the  information  sciences.  This  digital  antenna  is  indeed  a  system  problem 
that  requires  interdisciplinary  skills.  The  transition  from  a  relatively 
simple  dish  to  the  digital  antenna  is  happening  in  other  areas  as  veil. 

From  the  above,  we  may  conclude  that  a  good  system  engineer  needs  some 
special  attributes.  Among  them  are: 

A  mastery  at  tormuIating  and  solving  system-type  problems. 

The  talent  to  translate  operational  needs  into  technical  requirements. 

The  ability  to  direct  and  coordinate  multiple,  simultaneous  technical 
activities. 

A  capability  and  willingness  to  make  firm  engineering  and  management 
decisions . 

An  understanding  of  procurement  procedures  and  financial  management. 

A  sensitivity  to  the  factors  affecting  the  acceptability  of  his 
system  concept. 

The  technical  integrity  to  honestly  surface  and  face  issues. 

Although  system  engineers  may  evolve  out  of  one  of  the  engineering  disciplines 
which  are  involved  in  the  system  life  cycle,  the  new  breed  of  system  engineer 
must  have  a  good  working  knowledge  of  many  engineering  and  scientific  disciplines 
involved,  in  order  to  recognize  interdiscipl inary  problems  and  lead  or  participate 
in  their  solutions.  And  yet,  as  any  good  system  engineer,  he  must  also  be 
the  prime  mover  in  the  conceptual  and  analytic  studies  required;  he  must  deal 
creatively  and  decisively  with  technology,  people,  and  environments;  for  let 
us  not  forget  that  achievement  of  a  successful  system  also  requires  good 
management  of  the  system  engineering  functions .  1 12 , 13]  To  carry  out  any  program, 
an  engineering  organization  consisting  not  only  of  engineers  and  scientists 
is  needed,  but  also  technicians,  draftsmen,  programmers,  model  builders  and 
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non-technical  personnel  for  financial  management,  contracting,  etc.  The  efficient 
use  of  these  skills  must  be  planned  and  scheduled.  Goals  and  objective  schedules 
must  be  established.  Technical  direction  must  be  provided,  and  managerial 
controls  must  be  initiated. 

Modern  system  engineers  must  be  equipped  and  trained  to  use  modern  engineering 
tools,  especially  computer-aided  capabilities . 114]  Modern  system  engineers 
should  use  work  stations  which  are  equipped  with  software  packages  for  mathe¬ 
matical  and  statistical  analysis;  with  engineering  tools  for  design  and  analysis 
and  for  modelling  and  simulation.  They  should  include  aids  for  project  management — 
cost,  schedule,  and  performance  tracking;  cost  analysis  and  trends;  report 
generation.  And  all  of  these  require  suitable  graphics. 

The  prevailing  opinion  is  that  system  engineers  are  born,  not  made.  Most 
large  engineering  firms  and  so-called  system  houses  assign  system  engineering 
responsibilities  to  their  brighter,  accomplished  engineers  who  seem  to 
"think  big."  Many  of  the  skills  of  system  engineering  and  management  are 
acquired  through  years  of  experience,  and  talents  such  as  creativity  and  the 
ability  to  deal  with  complexity  may  be  innate  qualities.  However,  formal 
training  and  education  are  necessary  to  develop  and  provide: 

(1)  Interdisciplinary  skills  -  broad  knowledge  of  many  engineering 
disciplines  as  well  as  operations  research,  and  even 
manufacturing  processes.  Subjects  such  as  control  engineering, 
communications  theory,  signal  processing,  electromagnetics,  and 
information  processing  are  vital. 

(2)  Mathematical  skills  -  sufficient  knowledge  of  advanced  mathematics  to 
understand  and  direct  the  design  analyses  that  may  be  needed, 

(3)  Computation  skills  -  use  of  computers  for  analysis,  instrumentation, 
and  modelling  and  simulation. 

(4)  Management  and  Interpersonnel  skills  -  to  better  deal  with  people  and 
resources. 

This  new  breed  of  system  engineer  may  learn  some  valuable  lessons  from  the  emergence 

of  software  engineering  as  a  discipline.  The  software  engineer  is  well  aware 

of  the  steps  in  the  life-cycle  of  a  project.  An  integrated  software  engineering 

environment  is  emerging;  he  is  developing  tools  for  automated  prototyping 

and  for  the  evaluation  of  progress  in  the  development  of  software.  Artificial 

Intelligence/Expert  Systems  technology  is  being  applied  in  the  development 

of  software  tools  and  methodology  to  support  the  various  phases  in  the 

software  life  cycle,  and  to  provide  corporate  memory  such  as  the  rationale 

behind  design  decisions  made  throughout  the  life-cycle.  These  techniques 

for  software  engineering  are  also  being  applied  to  system  engineering  of  both 

hardware  as  well  as  software. 

Future  avionics  systems,  employing  new  technologies,  present  even  greater 
system  engineering  challenges.  One  may  envision  multiple  sensors, 
communications,  and  electronic  warfare  systems  sharing  a  common  adaptive 
phased  array;  we  may  anticipate  a  local  area  network  of  processors  sharing 
the  functions  of  control,  computation,  message  processing,  etc.;  and  we  can 
anticipate  intelligent  displays  that  will  provide  information  in  a  variety 
of  forms — graphics,  imagery,  text,  etc.  that  may  be  accessed  by  voice, 
by  keyboard,  or  by  touch.  This  implies  that  we  must  put  greater  emphasis 
on  architectures,  subsystem  design  and  interfaces  and  system  integration. 

Only  through  a  total  systems  engineering  approach  that  considers  these  factors 
from  the  very  initial  phases  of  the  system  life  cycle,  as  well  as 
modularity,  internal  communications,  standards,  reconfigurability,  and 
supportabili ty ,  may  we  achieve  well  engineered  systems.  The  payoff  will  be 
reduced  cost  of  ownership  and  greater  mission  effectiveness. 

This  lecture  series  will  introduce  to  the  system  engineer  and  the  potential 
system  engineer  some  of  the  basic  concepts  of  system  engineering.  Con¬ 
sidering  the  broad  scope  of  activities  involved,  these  lectures  concentrate 
on  the  initial  phase  of  the  system  life  cycle — requirements,  architecture, 
design.  Although  all  aspects  of  the  life-cycle  are  important,  the  more 
attention  given  "up  front",  the  less  likely  will  be  the  need  for  the 
occurrence  of  errors  and  costly  rework  in  the  later  stages  of  the  life-cycle. 

In  the  following  paper,  Dr  Paskin  addresses  the  avionics  requirements 
definition  process,  at  the  conceptual  level,  in  light  of  changing  threats, 
technology,  and  business  environments.  He  provides  a  perspective  of  total 
integrated  system  performance,  looking  at  broad  requirements  issues  rather 
than  specific  subsystem  specif ications.  His  fundamental  premise  is  that 
avionics  requirements  are  driven  by  four  factors;  Information  and  Data 


Sources#  Control  Opportunities  and  Information  Needs,  Concepts,  and 
Algorithmic  Techniques,  and  Realization  Technologies .  These  four  factors 
are  set  in  a  system  structure  which  shows  their  interrelationships  and 
provides  the  framework  for  conceptualizing  avionics  system  solutions  to 
meet  particular  mission  needs.  An  examination  is  made  of  the  issues  of 
fielding  and  affording  the  solution  with  specific  emphasis  on  architecture, 
fusion,  production,  and  support. 

Mr.  Rowle  will  describe  a  top-down  methodology  for  establi shment  of  design 
requirements.  He  will  describe  the  structured  design  of  the  avionics 
system  for  the  UK  Exper imental  Aircraft  Program  (EAP)  using  a  design  tool 
called  CORE  (Controlled  Requirements  Expression). 

Mr.  Breza  will  then  discuss  the  integration  of  avionics  into  the  overall 
conceptual  design  phase.  He  will  cover  methods  and  concepts  for  the  intro¬ 
duction  of  avionics  systems  in  the  initial  design  of  aeronautical  systems, 
describing  the  balanced  design  process  which  relates  avionics,  propulsion 
and  armament  systems.  This  involves  the  extension  of  current  aircraft  design 
synthesis  and  analysis  procedures  to  incorporate  avionics  in  order  to  achieve 
an  integrated  system  design  for  optimum  aeronautical  system  and  avionics 
system  parameters.  Quantifiable  measures  of  merit  and  the  optimization 
of  performance-to-cost  ratio  for  new  aeronautical  systems  are  described. 


Some  recent  examples  of  the  evolution  of  architectures  for  modern-day 
information  systems  are  presented  by  Mr.  Ostgaard,  DAIS  in  the  1970's  and 
Pave  Pillar  in  the  1980's.  The  Digital  Avionics  Information  System  (DAIS) 
was  a  system  architecture  for  an  avionic  system  utilizing  digital  technology 
to  reduce  life  cycle  costs  by  defining  and  developing  hardware  and  software 
core  elements  and  standardized  interfaces  which  could  be  configured  and  applied 
to  many  aircraft.  The  Pave  Pillar  program  established  an  avionics  architecture 
with  a  design  philosophy  which  permits  resource.,  to  be  shared  across  subsystems. 
This  requires  a  highly  coupled  system-wide  management  and  control  program 
(operating  system)  supported  by  a  wide-band  data  distribution  network,  high 
speed  processors,  and  extensive  mass  memory. 

The  next  series  of  lectures  will  be  devoted  to  avionics  system  design. 

Mr.  Tooze  will  first  describe  an  approach  to  avionics  system  design  and  its 
application  to  modular  avionics  architectures.  By  taking  various  architectures 
and  corresponding  modular  sets  and  applying  functional  descriptions  of  the 
requirement,  each  architectural  candidat  may  be  investigated  for  its 
capability  to  meet  the  expected  requi rer ants . 

Dr  Berardi  will  talk  about  rapid  prototyping,  but  with  emphasis  on  the 
growing  use  of  artificial  intelligence/expert  systems  for  rapid  prototyping. 

In  particular,  he  will  describe  a  design  tool  called  E-CATE  (Expert  Consultant 
for  Avionics  System  Transformat  ion  Exploitat ion ) ,  developed  by  Avionics  and 
Equipment  Group  of  Aeritalia.  This  is  an  expert  system  that  prototypes  the 
information  handling  architecture  of  an  avionics  system.  He  further  expands 
upon  the  use  of  artificial  intelligence  and  computer  tools  with  a  description 
cf  a  complete,  integrated  environment  for  the  rapid  development  of  software 
prototypes  of  avionics  systems. 

M.  Schirle  will  describe  the  use  of  rapid  prototyping  leading  to  detailed 
specifications  and  corresponding  test  plans.  He  will  describe  examples 
carried  out  in  the  Avions  Marcel  Dassaul t-Breguet  Aviation  company  through 
the  analysis  and  the  synthesis  of  the  rapid  prototyping  used  within  the  frame¬ 
work  of  Rafale  A  and  Mirage  2000  NC  systems  developments.  Although  emphasis- 
will  be  upon  the  practical  use  of  prototyping  and  the  results  gained,  he 
will  also  show  other  uses  and  benefits  of  prototyping. 

And  finally,  to  illustrate  the  impact  of  new  technology  and  its  introduction 
into  future  avionics  systems,  Mr  Ostgaard  will  describe  the  Pave  Pace  program. 
This  program  is  a  systematic  and  disciplined  approach  to  the  technology 
maturation  process  and  will  provide  the  system  definition  for  future 
development  and  demonstration  of  highly  capable  and  affordable  avionics 
technology  for  new/retrofitted  aircraft  in  the  21st  century.  It  addresses 
compatibility  with  existing  avionics  architectures  which  provide  new 
capabilities  in  machine  intelligence  to  provide  better  aircrew  situation 
awareness  and  decision  aiding  in  complex  scenarios,  ultra-reliable  electronics 
for  surge/austere  support  conditions,  and  system  level  computer  aided 
development  and  support  tools  to  reduce  embedded  computer  software  costs  . 
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SUMMARY 


This  paper  addresses  avionics  system  requirements  at  the  conceptual  level 
in  light  of  changing  threats,  acquisition  strategies,  technology,  and 
business  environments.  The  objective  is  to  provide  a  perspective  of  total 
integrated  avionics  system  performance  which  illuminates  broad 
requirements  issues  rather  than  specific  subsystem  specifications. 

The  fundamental  tenet  of  this  paper  is  that  although  one  can  intuitively 
relate  parametric  and  functional  avionic  system  requirements  to  mission 
related  activities,  a  more  global  view  is  necessary  to  ensure  that  system 
requirements  aptly  address  the  gamut  of  factors  Which  relentlessly  bear  on 
the  ultimate  system  design,  development,  production,  and  support.  The 
premise  is  that  avionics  requirements  are  driven  by  four  factors; 
Information  and  Data  Sources,  Control  Opportunities  and  Information  Needs, 
Concepts  and  Algorithmic  Techniques,  and  Realization  Technologies.  These 
four  factors  ire  set  In  a  generic  systems  structure  which  shows  their 
interrelationships  and  provides  the  framework  for  conceptualizing  avionic 
system  solutions  to  meet  particular  mission  needs.  The  structure  focuses 
on  t  '  role  of  avionics  in  providing  situation  assessment,  response 
selection,  response  implementation,  and  cov mun lea t ions .  With  this 
structure  in  place,  avionic  system  requirements  are  then  examined  within 
the  context  of  architecture,  techniques,  technology,  producibility,  and 
supportability .  Each  of  these  factors  play  a  major  role  in  deteimining  the 
ultimate  system  specifications  and  are  signif icantly  altering  the  design 
parameters  of  systems  as  we  know  them  today. 

The  importance  of  developing  the  rLght  avionic  system  requirements  in 
tomorrow’s  complex  weapon  systems  cannot  he  overstated.  It  is  the 
critical  first  step  in  the  commitment  of  vast  resources  to  multidecade 
design,  development,  production,  and  support  programs.  The  ultLmate 
measure  of  success  is  a  system  which  is  affordable  in  peace  time  and 
capable  in  wartime.  The  concepts  advanced  in  this  paper  arc  intended  to 
stimulate  the  move  in  this  direction. 


The  classical  approach  to  avionic  system  requirements  focuses  on  functional  entities  such  as 
surveillance,  targeting,  communicat ions ,  electronic  warfare,  etc.  This  approach  very  quickly  drives 
down  to  specific  parameiers  such  as  sensitivity,  dynamic  range,  power,  aperture  size,  and 

field  of  view,  associated  with  various  sensor  subsystems.  The  approach  is  quite  straight  forward  and 

inherently  pleasing  to  the  engineering  community  because  It  allows  rapid  immersion  into  design, 
development,  and  testing.  Unfortunately,  the  results  often  leave  the  operational  planner  and  user  with 
a  system  which  not  only  doesn't  meet  mission  requirements,  but  imposes  a  support  and  training  burden 
which  reduce-j  operational  availability  and  effectiveness.  The  fundamental  tenet  of  this  paper  is  that 
although  one  can  intuitively  relate  parametric  and  functional  avionic  system  requirements  to  mission 
related  activities,  a  more  global  view  is  necessary  to  ensure  that  system  requirements  aptly  address 
the  gamut  of  factors  Which  relentlessly  bear  on  the  ultimate  system  design,  development,  production, 
training,  and  support. 

If  we  step  back  from  the  microcoslm  of  system  functional  requirements  and  take  a  macroscopic  view 
of  factors  affecting  the  lifetime  of  avionic  systems,  we  can  readily  see  that  avionic  system 

requirements  are  driven  as  much  by  circumstance  as  by  function.  (Figure  1) 


Figure  1  AVIONIC  SYSTEM  REQUIREMENTS  ARE  DRIVEN  BY  CIRCUMSTANCES 

•  Threat 

•  Supportability 

•  Policy 

•  Acquisition  Strategy 

•  Funding 

•  Schedule 

Threat  is  usually  the  primary  circumstance  used  to  Justify  the  requirement  for  advanced  avionic 
systems,  and  normally  drives  the  performance  specifications.  Supportability  is  probably  the  second 
moat  important  driver  t>*-w  avionics  development*  s .  When  system  failure  rates  and  repair  costs  exceed 
availability  requirm  and  i  isra)  constraints,  replacement  becomes  a  primary  consideration. 

Spec  If  icat  lima  in  -A-  •  '.nstance  are  more  heavily  influenced  by  supportability  considerations  than 
threat  driven  perl characteristics.  With  the  need  for  the  system  justified,  the  evolution  of 
the  ultimate  coutig  is  heavily  influenced  by  the  remaining  circumstances  shown  in  Figure  1. 


Recent  policy  trends  are  driving  industry  towards  cost-sharing,  firm  fixed  price  development 
contracts  and  performance  warranties  that  have  a  definite  effect  on  the  ultimate  system.  The  potential 
financial  impacts  associated  with  these  policies  are  inherently  mitigated  with  lower  risk,  lower 
technology  approaches  to  the  solution.  Creativity  is  stifled  by  the  fiscal  reality  of  bottom-line 
constraints  at  the  corporate  level. 

Acquisition  strategies  are  also  playing  a  major  role  in  the  determination  of  avionic  system 
requirements.  The  use  of  prototyping  and  demonstratlon/valldation  programs  allows  a  more  creatLve 
approach  to  the  problem  as  well  as  the  time  and  resources  to  advent*  the  state-of-the-art. 
Non-Devclopmentai  Item  (HDD  policy  on  the  other  hand,  forces  a  trade  between  what  is  desired  and  what 
is  available  rather  than  what  is  desired  and  what  can  be  achieved. 

Funding  and  schedule  are  two  additional  circumstances  which  heav’ly  influence  avionic  system 
requirements.  The  amount,  timeliness,  and  continuity  of  funding,  as  well  as  the  schedule,  play 
dominant  roles  in  determining  what  technology  can  be  brought  to  bear  on  the  problem,  and  hence  the 
content  of  eventual  solution. 

A  recently  imposed  acquisition  strategy  in  the  U.s.  involves  the  use  of  modular  avionic 
specifications  derived  by  a  Joint  Integrated  Avionics  Working  Croup  ( JIAWG) .  The  intent  is  to 
standard*!/.*  form- fit- function  specifications  at  the  line  replacement  module  (LRU)  level  for  specific 
subsystem  components  such  as  power  supplies,  computers,  and  signal  processors.  This  activity  could 
have  a  significant  impact  on  eventual  system  performance  parameters  as  well  as  cost  and  supportability . 

With  an  awareness  of  and  sensitivity  to  the  circumstances  cited  above,  we  will  now  address 
avionics  requirements  by  examining  the  role  avionics  plays  in  contributing  to  weapon  system 
effectiveness.  In  every  system  in  which  avionics  are  used,  the  role  of  the  avionics  involves  one  or 
more  of  the  functions  illustrated  in  Figure  2. 

By  examining  mission  objectives  for  the  system  under  consideration,  one  can  arrive  at  a  very 
specific  set  of  data  and  information  necessary  to  assess  the  situation.  Given  the  situation,  a  number 
of  alternative  responses  are  normally  available,  and  upon  selection,  they  can  be  implemented  to  change 
the  situation  in  a  manner  which  achieves  the  desired  system  mission  objectives. 

Situation  assessment  normally  requires  knowledge  of  position,  movement,  and  intent  of  both 
f»  I ei idly  and  enemy  forces.  Parameters  of  interest  in  determining  avionics  requirements  for  situation 
assessment  ln>  Itide  field  of  regard,  field  of  view,  resolution,  update  rates,  false  alarms,  false 
dismissals,  and  time  to  formulate. 

Response  selection  is  the  process  of  deciding  which  of  the  available  options  to  use  and  when  to 
implement.  Time  to  select  and  effectiveness  are  the  key  parameters  which  drive  the  avionics 
requirements . 


Response  implements! ion  is  the  process  of  modifying  the  situation, 
availability,  timeliness,  and  effectiveness. 


Important  parameters  include 


Communications  is  the  vital  link  which  ties  the  system  together, 
man-to-man  interfaces.  Effectiveness  of  coutuunicat ion  is  measured 
timeliness,  and  interoperability. 


It  includes  man- machine  and 
by  its  clarity,  security, 


The  Role  qf.  Avionic^ 


FIGURE  2 
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Within  the  context  of  this  top-down  view  of  the  functions  of  avionics  systems ,  one  can  now 
consider  the  factors  which  drive  the  avionics  designs.  The  premise  of  this  paper  is  that  avionics 
specifications  and  designs  are  driven  by  four  factors:  Information  and  data  sources  (what  is 
available) ;  Control  opportunities  and  information  needs  (What  is  controllable) ;  Concepts  and 
algorithmic  techniques  (Ingenuity  and  axpertise);  and  Realization  technologies 

(Mechanitat Ion-Hardware/ Sof twere) .  This  concept  is  illustrated  In  Figure  3. 


FIGURE  3 

At  this  time,  one  of  the  two  key  points  of  this  paper  is  made:  THE  FIRST  CASUALTY  OF  WAR  IS 
IHTRICACY  -  A  ROBUST  FORCE  STRUCTURE  IS  REQUIRED.  As  shown  in  Figure  4,  It  is  absolutely  essential  to 
be  able  to  define  a  minimum  level  of  effectiveness  below  which  the  engagement  is  lost.  Increased 
system  complexity  may  increase  effectiveness  and  result  In  quicker  success  with  fewer  losses,  but  the 
minimum  essential  capability  must  not  be  sacrificed. 

The  four  factors  of  avionic  system  specification  and  design  can  now  be  examined  in  the  more 
familiar  contexts  of  the  development  and  operational  communities:  Architecture,  Techniques, 

Technology,  Producibillty,  and  Supportablllty . 


The  First  Casualty  of  War  Is  Intricacy 
A  Robust  Forca  Structure  Is  Required 


Essential 

Inter -System  ComewmtedWon  and  Coordination 

Enhanced  Whan  Vte  Links  Art  Up 
Effective  Whan  the  Chips  Art  Down 


- Complexity 


FIGURE  4 

Avionics  architectures  ere  driven  by  three  fundamental  requirements;  performance,  availability, 
and  cost.  Performance  is  enhanced  by  architectures  with  high  levels  of  interconnectivity  where 
information  and  data  at  high  bandwidths  are  fused  end  processed  to  provide  high  confidence  situation 
estimates  and  response  eelections.  Availability  Is  addressed  by  architectures  with  low  level 
parallelism  that  ensure  no  single  point  failure  modes  exist  for  achieving  the  desired  minimum  essential 
capability.  Cost  objectives  are  approached  by  designing  for  regular  repetitive  structures  which  use 
common  functional  hardware  modules  in  as  many  cases  as  possible. 
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Havolutionary  techniques  will  be  a  necessity  to  meet  information  requirements  in  the  complex 
electronic,  meteorological,  and  environmental  conditions  of  the  modem  battlefield.  Present  avionic 
systems  formulate  a  mostly  one-to-one  match  between  sensor  and  function.  Association  and  fusion  of 
aultisensor  data  is  rudimentary  and  limited  to  combinations  of  information  which  has  already  passed 
declaration  thresholds.  Final  results  are  built  on  layers  of  decisions  and  require  high  confidence 
data  near  the  front  end.  The  most  telling  weakness  of  these  fusion  techniques  is  that  If  no  one  sensor 
declares  an  object,  the  object  will  not  be  declared.  Furthermore,  the  problem  of  spatial  and  temporal 
association  drives  resolution,  boreslght,  and  false  alarm  requirements  which  result  In  design 
complexity  and  high  costs.  A  top  down  process  is  required,  one  on  which  the  final  result  is  built  on  a 
single  high  level  decision.  The  process  should  operate  on  variable  confidence  data  from  individual 
sensor  reports  and  declare  an  object  even  if  no  one  sensor  so  declares.  The  value  of  sensor 
contributions  should  be  Independent  and  Intricate  temporal  and  spatial  association  should  not  be 
required.  These  criteria  might  be  used  to  measure  the  effectiveness  of  **fuslon*'  efforts  as  avionic 
systems  evolve. 

Evolutionary  technology  will  be  the  key  to  future  avionics  system  implementation.  Four 
technologies  (gallium  arsenide,  mercury  cadmium  telluride.  Very  High  Speed  Integrated  Circuits,  and 
super  conductivity)  hold  the  promise  of  achieving  levels  of  miniaturization,  sensitivity,  and 
processing  throughput  which  will  enable  implementation  of  techniques  not  possible  today. 

Production  goals  will  continue  to  be  quantity,  quality,  and  low  cost.  Concurrent  engineering  and 
application  of  proven  techniques  such  as  statistical  process  control  and  the  Teguchl  Method  will  make 
it  possible  to  achieve  the  desired  levels  of  quality  at  substantially  reduced  cost  and  schedule. 

Supportabllity  is  one  of  the  most  critical  design  requirements  in  avionics  systems.  For  weapons 
systems  to  be  effective,  they  must  perform  adequately  when  they  work,  be  easily  maintained  and  fixed 
when  they  break,  and  not  break,  more  often  than  is  economically  and  operationally  acceptable,  it's 
important  to  recognize  that  most  avionic  systems  are  developed  and  procured  in  peace  time,  when  cost  is 
an  Issue.  The  design  requirement  for  supportabllity  should  be  a  system  which  is  affordable  in  peace 
time  and  sustainable  In  wartime.  This  means  more  than  just  high  reliability  and  more  redundancy. 
Figure  3  illustrates  three  approaches  to  avionic  system  architecture,  each  of  which  has  substantially 
different  Impacts  on  availability.  In  the  single  thread  architecture,  every  element  of  the  system  is 
contributing  towards  system  effectiveness.  When  a  failure  occurs,  the  system  effectiveness  drops  to 
zero  until  the  failed  element  is  repaired  or  replaced.  The  system  down  time  vs  a  function  of  the 
time-to-repair  or  time- to- rep lace  and  overall  availability  is  further  impacted  by  the  reliability  of 
the  individual  components.  To  compensate  for  inadequate  reliability,  backup  redundancy  is  often 
introduced  into  the  system.  In  this  type  of  redundant  architecture,  redundant  sub-eiements  await 
"failure  of  the  first  team  players"  and  then  step  in  to  fill  the  function.  The  system  continues  to 
meet  "spec  levels"  until  the  redundant  elements  degrade  to  single  thread  status  and  a  single  point 
failure  occurs.  Although  simple  in  concept,  this  type  of  architecture  is  the  least  cost  effective 
approach  to  availability.  The  system  is  overburdened  with  "spare  parts"  which  cost  dollars  and  weight 
and  only  "pay  for  themselves"  when  the  primary  component  fails. 


AVIOMICS  ARCHITECTURES  IMPACT  AVAILABILITY 


rYPE  ARCHITECTURE 


SINGLE  THREAD 


BACK  UP 
REDUNDANCY 


Availability  and  Supportabllity 


Effectiveness 
Spec  Level 


Time 


PARTICIPATIVE 

REDUNDANCY 


Effectiveness 
Spec  Level 
Crltlcel  Felture 


,  Redundancy 


Time 


FIGURE  5 


The  second  key  point  of  this  paper  is  now  stated.  SYSTEMS  SHOULD  HAVE  AH  ARCHITECTURE  WHICH 
GRACEFULLY  DEGRADES  TO  THE  HJHIHUM  ESSENTIAL  EFFECTI VBV8SS  BEFORE  HAIVTEHAHCE  IS  HAMDATORY.  This 
concept  is  illustrated  by  the  participative  redundancy  example  in  Figure  5.  Redundancy  is  used  to 
provide  capability  rather  than  back  uj  capability.  As  sub-elements  of  the  system  fall,  the 
effectiveness  degrades,  but  the  system  continues  to  operate.  Thus  we  introduce  the  notion  of  graceful 
degradation,  rather  than  the  strict  '‘fault  tolerance"  in  the  previous  architecture.  The  concept  is 
analagous  to  designing  system  sub-functions  in  an  "analog"  manner  so  they  degrade  like  a  flashlight 
battery  rather  than  a  light  bulb.  Light  bulbs  fail  catastrophically,  where  as  batteries  continue  to 
provide  capability  even  in  a  deteriorated  condition.  An  air-to-air  radar  system  would  still  provide 
effective  warfighting  capability  even  if  its  range  dropped  to  3/4,  2/3,  and  even  1/2  the  spec  value. 
The  challenge  is  to  develop  system  architecture  and  components  to  <.*  this  notion.  It  can  be 

done.  Electronically  scanned  antennas  are  an  example  (Figure  6).  Antennas  of  this  type  are  comprised 
of  multiple  phase  control  modules  (PCH's)  which  form  the  antenna  beam  pattern.  As  PCM's  fail,  the 
antenna  continues  to  operate  although  the  main  beam  pattern  broadens  and  the  gain  drops.  Even  after 
20%  of  the  PCH’s  fail,  the  sldelobes  still  permit  effective  detect  and  track  operation  (Figure  7)  and 
as  predicted  by  the  radar  range  equation,  the  range  is  at  +54%  of  full  capability  (Figure  8).  Pilots 
in  combat  would  still  have  sufficient  capability  to  engage  the  enemy,  even  with  a  system  in  this 
degraded  mode.  In  the  final  analysis,  that's  what  avionics  system  requirements  are  all  about. 
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FIGURE  8 

The  importance  of  developing  the  right  avionics  system  requirements  in  tomorrow's  complex  weapon 
systems  cannot  be  overstated.  Requirements  are  driven  by  a  number  of  complex  and  interacting 
circumstances.  Policy,  acquisition  strategy  and  funding  often  have  as  profound  an  effect  as  the  threat 
and  supportability.  A  global  view  of  requirements  from  the  perspective  of  situation  assessment, 
response  selection,  response  implementation,  and  communications  leads  one  to  consider  the  mission 
related  effectiveness  parameters  rather  than  specific  sensor  specifications  such  as  range,  sensitivity, 
sidelobes,  etc.  The  concept  of  a  minimum  essential  Level  of  effectiveness  sets  the  threshold  below 
which  system  performance  is  intolerable.  This  threshold  is  then  the  basis  upon  which  architecture, 
techniques,  and  technology  can  be  exercised  to  develop  a  cost  effective,  supportable,  total  quality 
system  which  will  provide  an  affordable  capability  during  peace  time  and  a  decisive  combat  advance 
during  wartime. 
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1 .  INTRODUCTION 

The  prime  purpose  of  this  paper  is  to  describe  a  structured  approach  to  the  design  of  a 
weapon  system  which  British  Aerospace  (BAe)  were  able  to  develop  and  prove  during  the 
design  of  the  avionics  system  for  the  Experimental  Aircraft  Programme  (EAP)  demonstrator 
aircraft.  This  aircraft  first  flew  in  the  United  Kingdom  in  August,  1986.  Brief 
descriptions  are  given  of  the  EAP  avionics  system,  the  main  system  design  tools  used,  the 
activities  carried  out  during  the  systems  design  process  and  the  management  and  control 
procedures  adopted.  In  addition  a  series  of  observations  highlighting  some  of  the  findings 
of  the  project  and  providing  pointers  to  the  design  of  future  weapon  systems  are  given. 

In  designing  the  Avionics  system  of  EAP,  BAe  developed  the  structural  approach  to  system 
design  called  CORE  -  controlled  Requirements  Expression.  This  method  of  functional 
definition  and  partitioning  ensure  that  a  methodical,  structured  approach  to  the  step  by 
step  process  of  progressive  development  is  maintained.  It  also  means  that  a  clearly 
partitioned,  well  documented,  unambiguous  and  easily  traceable  functional  design  is  pro¬ 
duced  which  can  readily  be  changed  without  loss  of  integrity  or  design  continuity. 

During  the  functional  design  process  outline  implementation  architectures  are  produced 
which  enable  optimum  partitioning  of  functions  to  be  achieved  recognising  practical 
constraints  such  as  "off  the  shelf"  equipment  in  addition  to  allocating  functions  so  as 
to  avoid  duplication  and  reduce  systems  weight.  Prior  to  EAP,  equipments  and  sub-systems 
have  been  produced  largely  on  a  stand  alone  basis  which  has  led  to  some  duplication, 
excess  weight  and  a  lack  of  optimisation  of  sy stem  performance.  Future  aircraft  will 
demand  that  weight  is  kept  to  an  absolute  minimum  since  it  is  critical  to  both  the  overall 
performance  of  the  vehicle  and  its  cost.  It  is  necessary  therefore  that  the  Avionics 
Systems  design  is  tackled  in  an  integrated  and  disciplined  manner  in  order  to  obtain  max¬ 
imum  performance  for  minimum  weight.  A  fully  integrated  weapons  system  design  removes 
possible  duplication  and  enables  some  equipments  to  under  take  several  functions.  rt  is 
the  complexity  and  interdependence  of  the  various  functions  involved  which  force  the 
weapon  system  designer  to  look  for  improved  design  techniques  which  must  include  to  fol¬ 
lowing  features 

a  step  by  step  approach  which  progressively  develops  the  design  rationale  and  which 
can  be  applied  across  the  whole  of  the  design.  This  in  turn  must  provide  a  capability 
for  planning  the  execution  of  the  design  and  for  monitoring  its  progress. 

a  precise,  consistent  and  unambiguous  way  of  expressing  system  requirements  at  all 
levels . 

a  means  of  applying  checks  at  different  stages  of  design  life  cycle  to  detect  errors 
of  specif ication  or  design  in  order  to  assure  the  design  quality. 

an  ability  to  demonstrate  that  the  requirements  have  been  met  in  order  to  assure  the 
design  quality. 

an  ability  to  demonstrate  that  the  requirements  have  been  met  in  order  to  provide 
traceability  of  the  requirements. 

a  capability  to  provide  configuration  control  of  the  design. 

These  are  the  principal  features  embedded  in  the  structured  approach  which  was  adopted  by 
BAe  for  the  design  of  the  avionic  systems  for  the  EAP  and  which  are  discussed  in  more 
detail  in  this  paper. 

2.  EAP 

While  EAP  has  been  created  relatively  quickly,  its  origins  go  back  at  least  ten  years. 

During  this  period  engineers  at  British  Aerospace,  Warton,  worked  on  various  studies  for 
a  new  fighter  aircraft  incorporating  twin  engines,  delta  wings,  canards  and  both  single 
and  twin  fins.  Some  of  these  studies  were  undertaken  in  collaboration  with  other  Companies. 
In  1979  a  proposal  for  a  European  Combat  Fighter  (ECF)  was  put  to  the  British  and  German 
governments  jointly  by  BAe  and  Messerschmitt-Bolkow-Blohm,  while  in  1980  a  slightly  modified 
design  for  a  European  Combat  Aircraft  (ECA)  was  prepared  by  BAe,  Dassault-Breguet  and  MBB 
and  put  to  their  respective  governments.  Unfortunately  the  governments  were  unable  to 
reach  agreement  on  a  common  set  of  requirements. 

During  1981  BAe  continued  its  studies  and  defined  the  P110  project  which  involved  the  UK 
Avionics  Industry  in  agreeing  a  weapon  system  architecture  and  producing  equipment  speci¬ 
fications.  At  the  same  time  MBB  were  working  up  their  TKF90  project  which  was  very 
similar  to  the  P110.  Therefore  in  April  1982,  the  three  companies  (AIT,  BAe  and  MBB)  who 
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had  previously  co-operated  to  design  and  build  the  Tornado  aircraft,  agreed  to  inves¬ 
tigate  the  possibilities  of  producing  a  joint  specification  to  meet  their  individual 
national  requirements.  The  resulting  Agile  Combat  Aircraft  (ACA)  was  unveiled  in  mock 
up  form  at  the  1982  Farnborough  Air  Show  and  the  UK  government  announced  that  they  would 
provide  support  for  a  demonstrator  aircraft  which  would  be  flown  at  the  1986  Farnborough 
Air  Show.  The  demonstrator  aircraft  was  to  be  called  the  EAP. 

It  was  anticipated  that  two  demonstrator  aircraft  based  on  the  ACA  design  would  be  built, 
one  in  Great  Britain  and  one  in  Germany.  During  1983  a  limited  systems  fit  was  agreed  for 
the  aircraft  and  due  to  the  tight  timescales  of  the  project,  equipment  specifications  were 
produced,  put  out  for  tender  and  Suppliers  selected,  very  much  in  advance  of  the  carrying 
out  of  a  detailed  system  design.  Unfortunately  as  a  result  of  the  German  and  Italian 
Governments  decisions  to  withdraw  at  the  end  of  1983,  work  on  the  German  aircraft  did  not 
proceed.  However  the  chosen  equipment  suppliers  from  the  three  countries  accepted  BAe ' s 
invitation  to  continue  with  the  design,  build  and  supply  of  the  numerous  equipments 
required,  from  their  own  funds,  for  the  single  demonstrator  aircraft. 

In  obtaining  the  agreement  of  the  UK  government  to  provide  support  for  the  demonstrator 
aircraft,  it  was  necessary  to  agree  the  objectives  which  would  be  demonstrated.  The  areas 
chosen  covered  the  fields  of  aerodynamics,  structures,  materials  and  systems  and  involved 
the  development  and  demonstration  of  procedures  necessary  for  the  design,  manufacture  and 
test  in  these  areas  which  were  considered  relevant  to  a  future  fighter  aircraft. 

This  paper  concentrates  on  the  work  carried  out  in  the  design  and  development  of  the 
avionics  system  involving  both  the  MIL  STD  1553b  data  bus  and  the  modern  electronic  cock¬ 
pit. 

3.  EAP  SYSTEMS 

The  EAP  has  three  major  electronic  systems:  Flight  Control  System,  Utilities  Services 
Management  Systems  and  Avionics  System,  the  latter  comprising  communications,  navigation 
and  display  and  control  subsystems.  A  simplified  system  architecture  is  shown  in  Fig  1. 

3 . 1  Flight  Control  System 

The  EAP  has  a  full  authority,  full  time,  digital  fly  by  wire  system  to  provide  artificial 
stability  and  the  necessary  complex  control  functions.  This  system  is  based  on  the 
Jaguar  Active  Control  technology  aircraft  which  was  the  first  aircraft  to  use  fly  by  wire 
for  flight  control  without  mechanical  backup.  The  system  controls  up  to  13  surfaces 
simultaneously.  The  four  identical  flight  control  computers  host  the  flight  software 
which  enables  the  pilot  to  fly  the  unstable  aircraft  and  provides  carefree  manoeuvrability 
and  increased  agility.  The  computers  also  hou^e  software  for  failure  management,  reversion 
logic  and  built-in-test.  The  computers  receive  inputs  from  the  four  aircraft  motion  sen¬ 
sors,  four  attitude  detectors,  two  air  data  computers  and  pilot  inceptors,  and  provide  the 
outputs  to  the  control  surfaces.  In  addition  they  provide  air  data  information  to  the  USMS 
and  avionics  systems  via  the  two  MIL  STD  1553B  data  buses  and  air  data  attitude  and  heading 
to  the  reversionary  instruments. 

3 . 2  Utility  Services  Management  System 

While  not  originally  claimed  as  a  technological  demonstration  feature,  th .  EAP  has  adopted 
an  integrated  computing  system  for  the  control  and  management  of  the  aircraft  utility 
system.  The  system  comprises  four  system  management  processors  connected  to  the  dual 
redundant  MIL  STD  1553B  data  bus.  The  bus  control  function  is  embedded  in  two  of  the 
processors.  The  main  utility  systems  which  are  controlled  by  the  processors  are  as 
follows: - 

fuel  management  and  fuel  gauging 

hydraulic  system  control  and  indication 

undercarriage  indication  and  monitoring,  wheel  brakes 

enviromental  control  system  including  cabin  temperature  control 

engine  control  and  indication 

secondary  power  system 

LOX  contents,  electrical  generation  and  battery  monitoring,  probe  heating 

The  main  benefits  of  this  type  of  system  for  a  high  performance  aircraft  are  a  significant 
reduction  in  installed  weight  and  operating  costs,  and  a  large  improvement  in  availability. 
It  also  provides  a  simple  interface  to  the  avionics  system  in  particular  for  the  cockpit 
electronic  displays  and  controls,  this  being  one  of  the  original  drivers  in  evolving  the 
system. 

3 . 3  Avionics  System 

It  was  accepted  that  for  the  EAP,  the  avionics  system  would  be  a  sub-set  of  the  weapon 
system  proposed  for  the  ACA.  This  was  called  the  "Core  System"  and  provides  the  essential 
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features  to  fly  a  high  performance  aircraft  namely  navigation,  communications,  and  displays 
and  control  functions.  Transmission  of  data  between  the  subsystems  is  via  a  dual  redundant 
MIL  STD  1553B  data  bus  which  greatly  reduces  the  amount  of  wire  required  in  the  aircraft 
and  simplifies  the  development  and  on-aircraft  testing. 

The  navigation  subsystem  comprises  an  inertial  platform  with  its  own  self-contained 
navigation  processor  and  a  TACAN  and  radar  altimeter  which  share  the  same  remote  terminal. 

The  communications  subsystem  comprises  a  standard  V/UHF  radio  and  an  emergency  UHF  radio. 
The  control  of  this  equipment  is  through  an  integrated  control  and  management  unit  which 
also  provides  a  voice  warning  facility.  The  latter  supplements  the  normal  aircraft 
warning  system. 

The  displays  and  controls  subsystem  demonstrates  several  new  technologies.  Twu  identical 
waveform  generators  form  the  heart  of  the  subsystem  and  are  each  capable  of  driving  the 
three  multi  function  colour  displays  and  the  wide  angle  holographic  headup  display.  They 
also  provide  the  bus  control  and  executive  control  functions  for  the  avionics  system. 
Mission  data  such  as  waypoints,  TACAN  beacons,  communication  channels  etc.,  are  inserted 
by  the  pilot  via  the  manual  data  entry  facility  mounted  on  the  left  hand  flareshield. 

This  information  together  with  raw  control  data  from  the  controls  mounted  on  the  consoles, 
throttles,  control  stick  and  displays  is  processed  in  two  identical  cockpit  interface 
units  prior  to  being  transmitted  on  the  avionics  data  bus.  A  cockpit  lighting  controller 
undertakes  the  task  of  monitoring  the  light  sensors  distributed  around  the  cockpit  and 
continuously  regulates  the  power  supplied  to  all  the  displays  and  controls  to  provide 
optimum  illumination  and  display  contrast  at  all  times. 

4 .  DESIGN  TOOLS 

In  parallel  with  the  work  being  carried  out  on  fighter  aircraft  studies  during  the  7G's, 

BAe  put  considerable  effort  into  examining  ways  of  improving  the  techniques  used  for 
designing  systems  and  also  into  the  newer  system  technologies .  Two  specific  areas  which 
showed  promise  and  were  pursued  with  the  support  of  the  UK  government,  were: 

means  of  improving  the  production  of  airborne  software  in  terms  of  productivity  and 
quality 

investigations  into  the  implementation  of  a  MIL  STD  1553B  databus  together  with  an 
all  "electronic"  cockpit  including  the  multi-moding  of  displays  and  controls. 

The  former  led  to  the  development  of  an  approach  called  Semi-Automated  Functional  Require¬ 
ment  Analysis  (SAFRA)  while  the  latter  led  to  the  production  of  the  Active  Cockpit.  Both 
of  these  tools  were  used  to  support  the  design  of  the  avionic  system  for  EAP  and  are 
described  in  the  following  paragraphs. 

4 . 1  Semi-Automated  Functional  Requirements  Analysis  (SAFRA) 

In  examining  ways  of  improving  the  productivity  and  quality  of  airborne  software  it  was 
shown  that  the  biggest  improvements  would  be  attained  by  the  ability  to  find  and  eliminate 
errors  at  as  early  a  stage  as  possible  in  the  software  life  cycle.  This  led  to  the 
development  of  the  approach  called  SAFRA  which  in  particular  addressed  the  lack  of  method, 
lack  of  visibility,  lack  of  consistency  and  resolution  of  ambiguities  in  producing 
software  requirements.  Just  as  this  method  was  applied  to  software  requirements  it  was 
shown  that  it  could  be  applied  to  the  establishing  of  system  requirements  and  was  there¬ 
fore  also  adopted  for  this  latter  purpose. 

The  SAFRA  approach  encompasses  a  number  of  methods  and  tools  which  support  the  various 
stages  of  the  system/software  life-cycle.  At  the  heart  of  SAFRA  is  a  method  called 
controlled  Requirements  Expression  (CORE)  which  is  used  to  produce  system  and  software 
requirements  that  are  unambiguous,  consistent  and  complete.  The  method  is  based  on  the 
progressive  decomposition  of  high  level  requirements  in  a  logical  and  consistent  manner 
until  a  level  is  reached  where  the  requirements  are  expressed  in  sufficiently  precise 
detail  to  allow  hardware  and  software  design  to  commence. 

Each  level  of  decomposition  consists  of  a  number  of  logical  steps,  eleven  in  all,  which 
when  applied  to  a  higher  level  requirement  produces  the  lower  level  components  of  the 
requirement.  These  steps  can  be  collectively  summarised  as  information  gathering,  estab¬ 
lishment  of  relationships ,  and  the  verification  of  relationships.  The  information  derived 
at  each  level  of  decomposition  is  presented  in  diagrammatic  form  known  as  CORE  diagrams. 
These  diagrams  use  a  precise  unambiguous  notation  which  can  be  checked  for  consistency 
and  completeness  across  the  whole  of  the  systems  requirement. 

To  assist  in  the  production  of  CORE  diagrams,  a  work  station  was  developed  which  enables 
diagrams  to  be  entered  at  a  high-resolution  graphics  terminal  and  edited  as  required.  It 
also  provides  a  multi-user  database  in  which  diagrams  are  stored  and  a  hard  copy  facility 
using  a  printer-plotter.  Some  automatic  on-line  checking  of  the  diagrams  for  consistency 
is  undertaken  as  they  are  being  entered. 

By  producing  the  requirements  in  an  unambiguous  form  in  a  computer  batabase  it  is  possible 
to  check  the  data  for  consistency  and  completeness.  This  was  done  using  PSL/PSA  (Problem 
Statement  Language/Problem  Statement  Analyser),  which  is  a  product  of  the  ISDOS  project 
of  the  University  of  Michigan,  although  other  similar  products  such  as  EPOS  are  now 
available.  The  CORE  notation  is  automatically  described  in  PSL  in  a  consistent  manner 
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and  stored  in  a  new  database.  PSA  is  then  used  to  provide  checking  and  analysis  of  the 
database  in  numerous  ways.  When  all  the  checks  have  been  satisfactorily  completed  at 
each  level  of  decomposition,  the  CORE  database  is  made  read-only  by  the  configuration 
controller  to  allow  the  next  stage  of  the  design  to  proceed. 

A . 2  Active  Cockpit 

As  the  result  of  its  continuing  development  studies,  BAe  gained  considerable  experience 
in  the  operation  of  active  cockpit  facilities  and  demonstrated  their  great  importance 
in  providing  information  on  the  man-machine  interface  to  the  system  design  process.  In 
effect  this  facility  provides  a  means  by  which  rapid  prototyping  of  ideas  can  be  tested 
and  developed  with  full  operator  interaction. 

The  Active  Cockpit  is  housed  in  a  wooden  shell  representing  the  actual  cockpit.  The  dis¬ 
plays  and  controls  are  positioned  according  to  the  best  information  available,  use  being 
made  of  commercial  items  wherever  possible.  Initially  static  displays  are  assessed  for 
the  development  of  the  moding  and  formats.  These  displays  are  then  driven  dynamically  in 
a  representative  manner  together  with  other  simulated  functions  such  as  engine,  hydraulics, 
fuel  etc.,  to  fully  exercise  the  cockpit  displays  and  controls.  To  allow  assessment  under 
realistic  flight  conditions  an  outside  world  simulation  system  is  provided.  In  addition 
a  comprehensive  fault  injection  system  is  used  to  allow  assessment  of  the  pilot/cockpit 
interface  when  single  or  multiple  system  failures  occur. 

5.  SYSTEM  DESIGN  ACTIVITIES 

The  life-cycle  stages  in  the  design  and  development  of  a  typical  system  are  illustrated 
in  figure  2.  These  can  be  grouped  under  three  main  headings  namely  system  design,  system 
implementation  and  system  test.  As  defined,  system  design  covers  the  stages  of  activity 
from  the  establishment  of  the  initial  high  level  system  requirement  through  several  levels 
of  decomposi tion  which  produce  the  detailed  requirements  including  hardware/software 
partitioning  to  the  production  of  hardware  and  software  specifications.  System  implemen¬ 
tation  covers  the  stages  from  the  availability  of  specifications  through  to  their  real¬ 
isation  in  either  hardware  or  software.  System  test  covers  the  stages  of  testing  starting 
with  individual  equipments  and  software  modules  and  building  up  individual  elements  to 
subsystems  and  finally  integrating  these  to  form  the  total  system. 

System  design  consists  of  4  activities  which  can  be  summarised  as: 

Design  Planning  -  This  is  the  establishment  of  a  design  plan  or  route  map  showing  the 
various  levels  of  functional  decomposition,  interdependence  between  functional  areas 
and  thus  design  team  tasks  and  documentation  requirements. 

Eata  Gathering  -  This  embraces  the  customer  requirement  and  relevant  pre-defined 
constraints  such  as  of f-the-shelf  equipments  and  research  findings,  together  with 
any  principles  and  philosophies  which  should  guide  the  design. 

Functional  Analysis  -  This  is  the  actual  functional  design  using  the  CORE  tool  for 
documenting,  analysing  and  validating  the  design  in  a  diagrammatic  manner .  To  provide 
sufficient  detail  the  Avionic  system  design  was  completed  in  three  stages  as  shown  in 
Fig  3 . 

Partitioning  -  This  is  the  activity  of  allocating  the  functions  to  equipment,  or  in 
the  case  of  multiprocessor  units,  to  specific  processors.  This  procedure  is  carried 
out  at  each  level  of  functional  definition  and  is  refined  as  increased  definition  is 
achi.  ved . 

A  good  example  of  optimum  partitioning  arose  during  the  EAP  design  when  having  determined 
the  major  functions  of  the  avionics  system,  it  was  necessary  to  decide  where  these 
functions  would  be  carried  out.  In  examining  locations  for  the  bus  control,  executive 
control,  display  management  and  symbol  generation  functions,  there  were  several  possible 
choices.  The  most  obvious  way  was  to  combine  the  bus  control  and  executive  control 
functions  in  a  single  equipment  and  the  display  management  and  symbol  generators  functions 
in  a  separate  equipment.  However  from  analysis  of  databus  traffic  it  was  shown  that  the 
databus  traffic  could  be  significantly  reduced  by  combining  all  four  functions  into  a 
single  equipment.  It  was  also  shown  that  by  using  a  single  equipment  significant  savings 
in  weight,  volume,  cabling,  power  and  cooling  would  result  and  finally  it  was  established 
with  potential  suppliers  that  this  solution  was  viable.  Thus  a  specification  for  a  wave¬ 
form  generator  which  undertook  all  four  functions,  was  put  out  to  tender. 

In  this  specific  case  the  main  operational  software  which  included  the  bus  control 
transaction  tables,  executive  control,  warnings  and  display  Management  functions  were 
produced  by  BAe  while  other  software  functions  for  bus  control  algorithm,  symbol  gener¬ 
ation,  built-in  test  and  basic  system  operating  modules  were  produced  by  the  equipment 
supplier.  This  combination  of  software  within  individual  processors  was  satisfactorily 
achieved  through  the  use  of  common  software  standards  and  tools. 

6 .  SYSTEM  MANAGEMENT  AND  CONTROL 

The  structured  design  process  v»ith  its  pre-defined  life  cycle  stages  provided  the  basis 
for  the  management  and  control  strategy.  Each  life  cycle  stage  has  a  specified  start 
point,  purpose  and  resultant  output.  Thus  as  the  life  cycle  unfolded  the  successful 
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completion  of  these  outputs  provided  management  with  the  necessary  measure  of  progress 
and  achievement. 

The  management  control  procedures,  to  which  all  life  cycle  stage  products  were  subjected 
can  be  summarised  as  follows:- 

Review  -  The  aim  of  this  is  to  ensure  both  the  satisfactory  completion  of  one  stage 
of  the  life  cycle  before  commencing  the  next  and  the  correct  planning  of  subsequent 
stages  to  achieve  successful  implementation.  The  review  was  both  technical  and 
managerial.  Technical;  to  check  both  automatically  and  through  independent  quality 
control#  that  the  design  was  compliant,  accurate,  traceable  and  conformed  to  standards, 
and  managerial  to  ensure  all  corrective  actions  were  resourced  and  progressed 
adequately. 

Configuration  Control  -  The  formal  review  having  been  completed  a  formal  baseline 
was  established  for  each  life  cycle  product  allowing  work  to  proceed  against  that 
formally  controlled  baseline.  As  more  detailed  work  continued  errors  were  exposed 
the  correction  of  which  were  rigorously  controlled  through  the  change  control 
procedure . 

-  Change  Control  -  Through  this  procedure  the  effect  of  a  change  on  all  potentially 
affected  areas  had  to  be  assessed  prior  to  approval  being  given  for  the  change. 

This  is  particularly  important  in  an  integrated  system  since  changes  in  one  processor 
can  cause  changes  in  other  processors.  if  the  change  was  sufficiently  large  or 
important  it  would  be  subjected  to  the  formal  review  process. 

Configuration  Status  Accounting  -  In  a  project  with  a  large  number  of  configuration 
controlled  items  and  an  even  larger  number  of  changes  in  progress  it  is  essential 
that  a  status  account  of  these  items  is  maintained  and  circulated  to  all  project 
participants.  In  addition  to  the  change  status  it  is  beneficial  to  maintain  an 
analysis  of  the  change  data. 

7 .  OBSERVATIONS  AND  CONCLUDING  REMARKS 

The  use  of  the  structured  design  approach  together  with  its  associated  tools  undoubtedly 
contributed  to  the  success  of  the  EAP  in  allowing  the  design  of  the  avionics  system  to 
achieve  a  high  standard  in  an  extremely  short  timescale.  The  following  specific  points 
are  considered  to  be  worthy  of  noting  summarising  what  was  learnt  from  this  exercise  and 
in  providing  pointers  to  the  design  of  future  weapon  systems. 

The  structured  approach  together  with  the  application  of  the  rigorous  management  and 
control  procedures  enabled  realistic  programme  plans  to  be  produced  and  provided  a 
high  level  of  visibility  in  terms  of  progress  of  the  design  activities.  The  change 
statistics  proved  to  be  a  valuable  indicator  of  how  the  project  expectations  and 
requirements  were  being  fulfilled. 

The  undertaking  of  a  freeze  of  the  systems  requirements  prior  to  starting  the  func¬ 
tional  analysis  process  and  then  the  application  of  a  strict  configuration  control 
procedure  which  virtually  eliminated  the  introduction  of  changes  to  these  require¬ 
ments  once  the  freeze  had  taken  place  were  considered  to  be  major  factors  in  enabling 
the  programme  timescale  to  be  met. 

The  use  of  the  structured  approach  brings  about  a  significant  increase  in  the  amount 
of  design  documentation  produced  but  this  is  greatly  assisted  by  the  use  of  computer 
aided  tools  which  reduce  the  labour  intensive  nature  of  this  task.  This  increase  in 
design  documentation  is  a  significant  step  forward  in  overcoming  past  deficiencies 
of  having  insufficient  information  readily  available.  It  also  significantly  reduces 
such  tasks  as  the  production  of  test  specifications,  customer  manuals  etc. 

The  key  to  the  production  of  a  high  quality  system  design  was  undoubtedly  the  insis¬ 
tence  on  the  adherence  to  the  very  rigid  control  and  management  of  the  design  process. 
CORE  proved  to  be  a  very  powerful  tool  not  only  for  design  but  also  for  fault  finding 
due  partly  to  the  extensive  documentation.  This  was  found  to  be  very  versatile  in 
assisting  the  engineers  to  rapidly  locate  the  problem  area  and  correct  it.  It  also 
enabled  changes  in  the  requirements  to  be  introduced  easily  and  rapidly. 

The  structured  approach  to  the  total  system  design  places  more  responsibility  on  the 
weapon  system  contractor  who  carries  out  the  partitioning  process,  and  therefore 
determines  where  and  how  the  various  functions  will  be  carried  out.  How  much  of  the 
resulting  activity  is  undertaken  by  the  weapon  system  contractor  or  the  avionic 
equipment  suppliers  is  a  matter  of  debate.  It  is  considered  that  avionics  suppliers 
will  continue  to  implement  the  specialist  functions  such  as  sensors,  displays  and 
processor  hardware  but  the  definition  of  the  on-board  software  will  become  more  the 
responsibility  of  the  weapon  system  contractor. 

As  well  as  the  tools  associated  with  SAFRA  which  were  used  to  assist  in  the  design  of 
EAP  systems,  use  was  also  made  of  mainframe  text  processors ,  minicomputer  word 
processors,  standard  proforma  and  data  base  tools.  For  future  projects,  the  extension  to 
a  comprehensive,  centralised,  computerised  engineering  database  is  considered  to  be 
highly  desirable. 
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In  any  project  there  is  a  need  for  effective  configuration  control  throughout  the 
design  phase.  On  EAP  this  was  handled  by  manual  means  supported  wherever  possible 
with  computer  aids.  As  the  size  of  a  project  increases  and  the  use  of  a  centralised 
engineering  data  base  with  multi-user  access  is  established,  so  automated  configur¬ 
ation  control  tools  must  be  available. 

It  is  considered  that  complex  system  requirements  cannot  be  accurately  described  in 
.plain  "English"  text.  The  use  of  tools  such  as  CORE  generate  their  own  design  lan¬ 
guage  and  introduce  a  need  for  training  not  only  of  the  system  design  engineers  but 
of  all  the  personnel  who  will  be  associated  with  the  project  such  as  test  engineers, 
support  engineers  and  in  particular  managers  and  representatives  of  the  customer. 

It  is  extremely  important  that  the  latter  two  groups  of  people  fully  appreciate  the 
design  approach  being  undertaken  and  its  associated  documentation. 

A  major  difference  between  the  structured  "top-down"  approach  compared  to  existing 
"bottom  up"  approaches,  is  the  elapsed  time  before  some  functioning  of  the  system  can 
be  seen.  In  the  latter  case  it  is  usual  for  some  areas  of  the  system  to  become 
visible  early  in  the  programme,  but  in  the  former  case  the  system  tends  to  come  to¬ 
gether  all  at  once,  albeit  on  time.  Management  must  be  made  aware  of  this  difference 
from  the  start  of  the  programme  and  must  rely  on  the  visibility  of  progress  provided 
by  the  method,  to  justify  their  faith  that  the  System  Designers  will  meet  their 
objectives . 

In  conclusion  it  must  be  admitted  that  there  were  doubts  during  the  initial  stages  of  the 
project  as  to  whether  the  structured  design  approach  was  sufficiently  developed  to  enable 
us  to  achieve  our  declared  objectives.  In  retrospect  the  success  of  the  project  in 
achieving  35  flights  in  the  first  30  days  with  no  requirements  for  system  changes,  shows 
that  the  doubts  were  unfounded.  In  particular,  the  success  of  the  structured  design  ap¬ 
proach  applied  to  the  avionics  system  in  terms  of  the  quality  of  design,  the  timescale 
achieved  and  its  supportability  were  beyond  our  expectations  and  indicates  the  way  forward 
for  the  design  of  the  more  complex  weapon  systems  of  the  future. 
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INTEGRATED  AVIONICS  -  CONCEPTUAL  DESIGN 
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ABSTRACT 

Avionics  of  modem  military  aircraft  is  essential  for  maximizing  performance  realization  of  the  total 
aeronautical  system.  In  the  early  conceptual  phase,  aeronautical  sy starts  designers  give  scant  attention 
to  the  interaction  of  avionics  components.  The  aircraft  design  team  generally  provides  vreight,  volune 
and  power  considerations  for  the  desired  avionics  functions  and  assumes  that  an  avionics  suite  can 
eventually  be  assembled.  Even  less  attention  is  given  to  the  potential  synergistic  effect  avionics  can 
have  with  the  aircraft  design  process.  In  contrast,  the  designers  expend  a  large  effort  on  f biding  the 
best  balanced  cartoination  of  airframe  and  propulsion  corrpanents  which  satisfy  the  design  objectives. 

This  paper  will  attempt  to  shew  why  avionics  must  be  a  co-equal  member  of  the  aeronautical  system  along 
with  airframe,  propulsion,  and  armament.  In  beaming  a  co-equal  partner,  avionics  must  be  an  element  of 
the  system  design  analysis,  ccmencing  with  the  early  conceptual  design  phase  of  a  new  aeronautical  system. 


Introduction 

During  the  conceptual  design  phase  of  military  aeronautical  systems,  considerable  attention  is 
placed  on  conducting  tradeoff  analyses  with  airframe  and  propulsion  related  parameters.  The  purpose  of 
these  tradeoff  studies  is  to  find  the  best  ccmbmation  of  wing  size,  wing  shape  (aspect  ratio,  sweep 
angle,  thickness) ,  engine  characteristics,  and  itany  other  configuration  parameters  to  best  fulfill  the 
flight  performance  objectives. 

Current  conceptual  design  practices  do  not  allow  the  avionics  parameters  to  play  in  the  design  trade¬ 
off  and  optimization  process.  Certainly,  aircraft  designers  are  aware  that  avionics  systems  are  important 
to  the  total  aeronautical  system.  Thus,  they  establish  allocations  that  account  for  the  presence  of  the 
avionics  cortpcrvents  within  the  aircraft,  Ttese  allocations  are  specified  in  terms  of  volume,  weight, 
electrical  power,  and  cooling  requirements.  Additionally,  the  designers  do  consider  same  of  the  very 
obvious  constraints  inposed  by  certain  sensors.  For  exanple,  rhe  fire  control  radar  must  be  located  to 
provide  a  large,  unobstructed  field  of  view. 

At  the  present  time,  the  aeronautical  system  designer  accepts  these  constraints.  Their  acceptance 
may  come  with  reluctance,  but  nonetheless,  these  constraints  are  accepted  like  other  constraints  inposed 
by  flight  crew  and  payload  provisions. 

The  Need 


Avionics  need  a  co-equal  t^trtner  with  the  airframe,  propulsion,  and  armament  carponents,  and  sub¬ 
jected  to  design  iterations  along  with  the  other  aircraft  carponents.  Why  should  the  avionics  system 
parameters  be  subjected  to  iteration  with  airframe,  propulsion,  and  armament  parameters  in  the  early  con¬ 
ceptual  design  tradeoff  process?  The  answer  to  this  question  seems  obvious.  First,  the  avionics  systems 
costs  are  a  major  portion  of  the  total  system  costs.  For  a  modem  fighter  or  attack  aircraft,  the  avion¬ 
ics  system  will  probably  cost  wore  than  either  the  airframe  or  propulsion  systans.  The  second  and 
probably  more  important  reason  is  that  avionics  are  essential  elanents  in  the  effectiveness  of  an  aero¬ 
nautical  oarbat  system.  Sinply  stated,  modem  combat  aircraft  cannot  acccnplish  its  task  without  an 
avionics  complement. 

Since  the  avionics  suite  in  itself  is  critical  to  the  mission  acocrpl islxnent ,  it  also  has  profound 
interactions  with  the  airframe,  propulsion,  armament,  and,  of  course,  very  significant  interactions  with 
the  pilot.  To  exanine  these  interactions,  there  is  a  need  to  make  avionics  conceptual  design  an  integral 
part  of  the  concept  formulation  process  of  advanced  aeronautical  systems. 

Due  to  ever  increasing  avionics  ccrplexity,  these  carponents  of  modern  military  aircraft  new  signif¬ 
icantly  inpact  the  cost  and  utility  of  the  total  vaaapon  system.  Avionics  requirements  are  usually  defined 
in  operational  terms  (e.g. ,  detection  range,  field  of  view/regard)  and  not  in  terms  of  design  parameters 
(e.g. ,  ban!  width,  prf,  NEI,  etc)  which  the  design  engineers  can  relate  to.  Typically  an  "allocation"  in 
terms  of  weight,  size,  power  and  cooling  needs  is  made  to  account  for  the  presence  of  the  avionics  suite 
inside  the  aeronautical  system.  As  to  what  subsystems  make  up  the  avionics  suite  and  how  they  are  related 
to  the  operational  task  is  left  far  later  definition.  Mich  of  the  aircraft  configuration  is  frozen.  The 
drawback  with  this  approach  is  that  it  gives  inadequate  attention  to  the  interacting  effects  avionics  have 
with  the  airframe/propulsion  systems.  Thus,  the  process  of  arriving  at  the  "best"  total  design  for  the 
mission  is  fundamentally  incomplete. 

To  incorporate  avionics  into  the  aircraft  design  process,  the  aircraft  design  team  has  to  integrate 
the  inputs  of  all  participants  involved  with  the  system  development  process.  These  oarticipants  include 
the  designer,  the  operational  user,  and  the  technologist.  Each  of  the  participants  concerns  must  be 
properly  within  the  framework  of  the  overall  system  to  insure  that  an  effective  and  affordable 

advanced  aeronautical  system  can  be  produced  with  low  risk.  Hew  these  participants  do  their  particular 
job  and  how  they  interact  in  arriving  at  a  system  solution  will  be  discussed  below. 


Currently,  in  --ne  early  stages  of  the  aircraft  design  process,  aircraft  design  teams  spend  consider¬ 
able  effort  determining  the  best  balanced  set  of  airframe  and  propulsion  parameters  that  achieve  the 
design  objectives.  To  accarplish  this,  the  design  team  formulates  an  aircraft  design  synthesis  and  anal¬ 
ysis  procedure.  Typically,  the  design  synthesis  and  analysis  procedure  is  formulated  within  the  organi¬ 
zations'  ccrputer-aided  design  system.  Once  the  procedure  is  established,  the  design  team  will  utilize 
the  procedure  bo  systematically  generate  an  array  of  aircraft  design  possibilities.  Within  the  design 
array,  the  major  configuration  design  variables  such  as  wing  size,  wing  shape,  sweep  angle,  fuselage 
length  and  diameter,  number  of  engines  and  engine  thrust  size  will  be  examined.  For  the  aircraft  perfor¬ 
mance  analysis,  different  measures  of  merit  are  used  depending  on  the  aircraft's  intended  mission.  Gen¬ 
erally,  the  aircraft  design  team  is  interested  in  flight  range,  maximum  speed,  maximum  turn  rate,  etc. 
Aircraft  cost  is  also  computed  based  on  data  derived  from  the  design  synthesis  process. 

The  inclusion  of  avionics  design  in  the  conceptual  design  process  appears  feasible.  Obviously,  the 
new  conceptual  design  system  world  have  a  number  of  new  input  parameters.  Also,  different  measures  of 
merit  are  required  to  assess  avionics  performance.  These  new  measures  of  merit  must  be  clearly  defined. 
There  are  a  myriad  of  measures  of  merit  used  to  characterize  avionics  performance  that  can  also  be 
linked  bo  the  aircraft  performance.  For  example,  aircraft  velocity  and  altitude  inpact  the  performance 
of  sane  sensors  and  the  aircraft's  configuration  may  limit  a  sensor’s  field  of  view.  Also,  avionics 
performance  is  strongly  coupled  to  sane  newer  aircraft  performance  measures  such  as  infrared  signature  and 
radar  cross-section.  A  reduced  signature  airframe  would,  for  exanple,  allow  a  reduction  in  ECM  output 
power  and,  hence,  weight  necessary  to  defeat  a  threat. 

TO  merge  avionics  requirements  into  the  total  aeronautical  system  design  process,  suitable  design 
methods  are  needed.  In  the  conceptual  design  phase,  where  there  is  little  or  ill  defined  avionics  hard¬ 
ware,  it  will  be  necessary  to  construct  mathematical  models  that  synthesize  the  avionics  suite  within  the 
overall  system.  These  models  need  not  be  extremely  elaborate,  but  must  have  sufficient  detail  to  provide 
the  definition  needed  for  the  avionics  performance  and  cost  analysis.  Also,  these  models  must  provide 
a  preliminary  assessment  of  the  volume,  weight,  pcwer  and  cooling  requirements  that  inpact  the  airframe 
and  propulsion  systems. 

The  avionics  system  performance  can  then  be  evaluated  within  the  total  aeronautical  system  design 
process.  Many  of  the  ccnpu ta t iona 1  tools  required  to  conduct  the  avionics  performance  analysis  already 
exist.  It  is  just  a  matter  of  utilizing  these  tools  earlier  in  the  aeronautical  system  design  process. 

Once  the  i*_w  integrated  design  synthesis  and  analysis  procedure  is  established,  numerous  trade 
studies  can  be  conducted.  Then  it  will  be  possible  to  examine  the  interactions  that  exist  between  the 
avionics  suite  and  the  other  major  components  of  the  aeronautical  system.  The  question  of  which  ccnbina- 
tion  of  sensors  should  be  used  in  a  given  weapon  system  could  then  be  examined  in  quantitative  terms. 

This  will  aid  greatly  in  preventing  the  over- specification  of  subsystem  requirements  and  consequent  high 
cost. 

Interaction  with  the  User 

Another  inportant  participant  in  the  process  of  avionics  into  the  aeronautical  system  conceptual 
design  process  is  the  user  of  the  aircraft.  The  aircraft  users  are  generally  the  military  combat  carmands 
like  the  Tactical  Air  Ccmnand,  Strategic  Air  Ccrmand,  etc.  In  tte  Air  Force,  the  cawnarxls  make  their 
requirements  known  by  issuing  Statements  of  Need  (SCN) .  The  level  of  detail  of  the  SON  can  vary  from 
stating  specific  performance  levels  like  detection  range  to  very  general  statements  like  "it  shall  be 
able  to  detect."  A  problem  frequently  arises  when  the  user  specifies  a  level  of  performance  that  is 
difficult  or  very  expensive  to  achieve  with  available  technology.  When  this  situation  occurs,  it  is 
necessary  to  work  with  the  using  command  to  evolve  a  set  of  design  requirements  that  are  technically 
viable,  reasonable  in  cost,  and  still  provide  the  margin  of  military  utility.  In  establishing  this 
dialogue  with  the  user,  it  is  necessary  to  examine  the  effect  that  user  requirements  have  on  the  total 
aeronautical  system's  cost  ~nd  performance. 

Interaction  with  the  Technologist 

Another  inportant  participant  in  the  process  of  introducing  avionics  into  the  aircraft  design 
process  is  the  technologies.  The  technologist  as  defined  here  are  the  scientists  and  engineers  who 
mature  relevant  technologies  for  transition  into  new  systems.  They  are  the  people  who  provide  new 
system  performance  opportunities.  In  the  course  of  maturing  technologies,  they  build  experimental 
articles  to  conduct  both  laboratory  and  field  tests.  Frequently,  prototype  articles  are 
flight  tested  in  a  "reed  world"  envirorment.  The  prototype  equipment  and  tests  conducted  ,  •>>.  rery 

valuable  database  for  interpretation  and  application  by  the  aircraft  design  team. 

This  database  can  provide  part  of  the  foundation  for  the  mathematical  models  used  in  the  integrated 
aircraft/avionics  design  synthesis  and  analysis  methodology.  The  avionics  specialist  on  the  design  team 
works  closely  with  the  technologist  to  insure  that  the  database  contains  all  the  information  needed. 

The  test  hardware  provides  the  necessary  physical  data  such  as  size,  weight,  power  required,  etc.  The 
test  results  provide  the  performance  data  and  all  conditional  information  which  affects  the  performance. 
The  designers  need  to  knew  the  environment  and  other  conditions  which  degrade  or  restrict  the  device's 
performance.  Having  a  sound  and  complete  database,  the  design  team  will  then  be  able  to  evaluate  not 
only  the  proposed  device,  but  also  synthesize  variations  of  that  device. 

Armament  Considerations 

Armament  technology  is  another  area  that  the  avionics  conceptual  designer  and  integrator  irust 
be  intinately  aware  of.  The  accuracy  and  effectiveness  of  weapons  delivery  systems — fire  control  for 
both  guns  and  missiles,  both  short  and  medium  range— depends  on  the  appropriate  matching  of  the  fire 
control  sensor  with  the  weapon  capability.  Here  also,  the  avionics  suite's  performance  requirements 
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have  to  natch  the  anticipated  capability  of  the  armament.  A  reactive  threat  that  responds  to  our  system 
improvements  by  improvements  in  kind  (such  as  those  involving  lower  signatures,  emissions ,  or  tactics) 
mast  also  be  considered  as  part  of  the  design  process.  This  would  require  a  capability  to  conduct  sensi¬ 
tivity  analysis  on  threat  reaction  to  identify  those  attributes  that  could  drive  our  avionics  performance 
tcwards  unacceptability. 

An  Avionics /Aircraft  Design  Trade  Exanple 

The  issue  of  one  versus  two  crew  members  in  a  fighter/attack  aircraft  has  been  long  standing.  The 
argument  centers  on  the  subject  of  the  pilot  vrork  load  versus  the  capability  of  the  electronics  aids  that 
can  be  made  available  to  reduce  the  pilot's  work  load.  The  topics  of  mission  effectiveness  and  the 
aircraft's  life  cycle  cost  strongly  inpact  this  issue.  Revolutionary  changes  that  are  occurring  in 
information  processing  and  displays  will  undoubtedly  cause  the  issue  of  cne  versus  two  crew  matters  to 
continue.  If  we  go  with  one  pilot,  the  inclusion  of  a  FLIP  with  a  field  of  regard  (FOR)  equivalent  to 
that  of  a  pilot’s  view  is  of  current  interest.  A  location  in  the  nose  of  the  aircraft  would  be  a 
necessary  constraint  to  satisfy  this  FOR.  However,  to  obtain  reasonable  sensor  recognition  performance, 
the  aperature  size  and  the  associated  housing  could  create  aerodynamic  problems.  Hence,  aperature/ sensor 
performance/aerodynamic  iiipact  trades  must  be  made. 

An  integrated  aircraft/avionics  design  synthesis  and  analysis  procedure  will  give  the  conceptual 
design  team  an  ability  to  quantify  design  issues  that  are  currently  the  subject  of  much  conjecture. 

Conclusions 

Much  work  needs  to  be  done  to  insure  that  avionics  are  satisfactorily  considered  in  the  aeronautical 
system  design  process.  It  is  technically  feasible  to  make  avionics  an  equal  partner  with  the  airframe, 
propulsion  and  armament  components  even  in  the  early  conceptual  design  phase  of  a  new  aeronautical  system. 
Current  aircraft  design  synthesis  and  analysis  procedures  can  be  modified  (and/or  expanded)  to  incorporate 
an  avionics  suite  synthesis  and  analysis  procedure  that  is  integral  to  the  overall  aeronautical  system 
design  methodology.  The  new  integrated  design  system  could  then  be  utilized  to  define  the  best  set  of 
aeronautical  system  design  parameters,  including  the  avionics  suite.  By  incorporating  avionics  considera¬ 
tions  into  the  aeronautical  system  design  process  with  quantifiable  measures  of  merit,  the  performance- to- 
cost  ratio  of  our  new  aeronautical  weapon  systems  will  improve  dramatically. 
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SUMMARY 


Thin  article  encompasses  the  evolutionary  design/development  of  modern-day  digital 
information  systems.  Included  are  the  Initial  attempts  at  using  digital  technology  in 
the  early  1970s,  the  system  integration  thrusts  of  the  1980s  and  the  continued  svstem 
technology  revolution  of  che  1990s. 

DAIS  -  1970s 

The  Digital  Avionics  Information  System  (DAIS)  was  the  first  attempt  at  defining  a 
system  architecture  for  an  avionic  system  utilizing  digital  technology  to  reduce  life 
cycle  costs.  The  strategy  was  to  develop  hardware  and  software  core  elements  and 
standardized  Interfaces  which  could  be  configured  and  applied  to  many  aircraft. 

The  DAIS  architecture  consisted  of  federated  processors  communicating  with  each 
other  and  the  other  system  elements  (sensors,  weapons,  and  controls  and  displays) 
through  a  standardized  multiplex  data  bus.  Centralized  system  single-point  control  was 
performed  by  a  processor  resident  software  executive  that  could  be  relocated  for 
redundancy.  Application  software  was  structured  to  provide  modularity,  reliability,  and 
transferability.  This  system  architecture  was  flexible  to  accommodate  a  wide  variety  of 
avionics  configurations,  missions,  and  sensors,  which  provided  redundancy  to  improve 
availability,  and  accommodate  changes  in  technology. 

The  basi'-  architecture  was  designed  for  a  broad  class  of  configurations  where  the 
number  of  processors  could  be  reduced  or  enlarged  depending  upon  the  avionics  and 
mission  requirements.  Standardization,  commonality  and  application  independent 
executive  software  allowed  adaptability  of  this  architecture  to  a  broad  class  of 
different  applications  ns  well  as  to  making  m t s s i on - 1 o-m i s s i on  changes  in  a  particular 
aircraft. 

LAVE  PILLAR  -  1980s 

The  PAVE  PILLAR  program  Las  established  an  avionics  architecture  for  tactical,  and 
strategic  aircraft  using  revolutionary  new  technology.  Tiie  trend  In  avionics  system 
design  Is  to  increase  system  integration  thereby  improving  system  performance, 
increasing  system  availability,  and  decreasing  cost  of  ownership.  The  PAVF.  PILLAR 
design  philosophy,  which  permits  resources  to  he  shared  across  subsystems,  requires  a 
highly  coupled  system-wide  management  and  control  program  (operating  system)  supported 
hv  a  wide-band  data  distribution  network,  high  speed  processors,  and  extensive  mass 
memory.  The  ability  to  consider  integration  of  this  magnitude  is  dependent  on  recent 
advances  in  microelectronics  technology,  most  notably  the  advent  of  VHSIC  and  fiber 
optics  technology. 

The  PAVE  PTLLAR  avionics  architecture  fs  functionally  divided  into  three  distinct 
areas:  mission  management,  sensor  management  and  vehicle  management.  The  three  areas 
define  che  enclosing  boundaries  for  resource  sharing,  sparing  and  substitution.  Unique 
characteristics  of  each  of  these  areas  preclude  the  utilization  of  resources  across 
areas  for  the  purpose  of  function  recovery  or  reconfiguration.  This  does  not  imply  that 
the  areas  do  not  contain  many  common  hardware  elements,  but  that  the  organization, 
connectivity  and  control  of  these  components  restrict  their  practical  use  in  functional 
system-wide  reassignment.  Each  of  the  three  areas  have  associated  with  them  a  logical 
processor  type  and  varying  interface  requirements.  The  Implementation  concept  is  for 
system  elements  to  be  built  from  a  set  of  common  modules  supporting  programmable 
processing,  1/0  and  memory  storage  functions.  The  interfaces  between  system  elements 
are  standard  high-speed  time  division  multiplex  buses  and  data  links,  all  utilizing 
M  b  e  r  optics  technology. 


PAVF  PACE  -  1990s 

An  avionics  technology  base  o f  historic  proportions  is  currently  being  sponsored  by 
United  States  government  PSD  agercies.  If  these  technologies  are  properly  exploited, 
matured  and  integrated  during  the  L990s,  2lsf  century  avionics  will  undergo  a  change 
that  x ay  he  as  dramatic  as  the  introduction  of  the  transistor.  Increasing  avionics 
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capabilities  while  decreasing  avionics  acquisition  and  BUpport  costs  will  be  a 
continuing  challenge.  This  program  Is  a  systematic  and  disciplined  approach  to  the 
technology  maturation  process  and  will  provide  the  system  definition  for  future 
development  and  demonstration  of  highly  capable  and  affordable  avionics  technology  for 
new/retrofitted  aircraft  in  the  21st  century.  Complete  compatibility  with  the  PAVE 
P1LLAR/ATF  Advanced  Avionics  Architecture  will  be  maintained.  New  Capabilities  to  be 
provided  include:  machine  intelligence  to  provide  better  aircrew  situation  awareness 
and  decision  aiding  in  complex  scenarios,  ultra-reliable  electronics  for  surge/austere 
support  conditions,  and  system  level  computer-aided  development  and  support  tools  to 
reduce  embedded  computer  software  costs. 

INTRODUCTION 


One  of  the  principal  trends  in  avionics  has  been  and  continues  to  be  from  analog  to 
digital  electronics.  The  rapid  growth  of  solid  state  micro-electronics  and  its  general 
commercial  availability  has  been  responsible  for  this  trend.  Applications  have 
progressed  from  simple  replacement  of  "conventional"  analog  components  like  vacuum  tubes 
and  discrete  components  by  solid  state  equivalents,  to  function  replacement  by  solid 
state  logic  arrays,  finally  to  total  Implementation  of  system  functions  by  solid  state. 
Integrated  circuits,  including  full  computer  processing  capability. 

Another  dominant  trend  has  been  to  integrated  system  architectures  where  digital 
subsystems  are  closely  coupled  under  software  control,  exchanging  digital  data,  to 
perform  a  total  weapon  system  function. 

These  trends  have  greatly  increased  the  performance  and  capabilities  of  our  weapon 
systems,  although  at  the  costs  of  increased  system  complexity.  The  gains  we  have 
achieved  in  improved  system  performance,  decreased  weight  and  volume,  lower  power 
consumption,  increased  reliability  and  lower  cost  per  function  by  the  use  of  high 
density  solid  state  micro-electronics  have  been  offset,  to  some  degree,  by  penalties  we 
now  have  to  pay  in  longer  and  more  complex  system  integration  programs,  software  design 
and  management  and  generally  more  soph  1st icated  logistical  support. 

A  relatively  recent  concern  is  the  short  "lifetime"  that  many  micro-electronic 
products  exhibit,  as  technology  continues  to  rapidly  evo’ve  and  companies  move  on  to 
broader,  more  profitable  markets.  A  five  year  product  life  cycle  is  not  very  compatible 
with  a  25-year  weapon  system  life  cycle. 

Given  that  most  people  will  admit  that  avionics  systems  employing  modern 
micro-electronics  and  real-time  software  carry  their  own  unique  class  of  problems,  the-e 
is  still  a  natural  resistance  by  the  system  designers  to  any  attempt  by  the  customer  to 
specify  system  characteristics  beyond  required  performance.  That  is  why  there  has  been 
some  rocky  going  as  we  cautiously  implement  a  number  of  standardization  concepts  and 
actual  architecture  related  standards.  However,  there  has  been  steady  progress. 

Progress  has  been  fastest  and  easiest  when  we  have  stayed  in  the  domain  of 
interface  standards.  The  implementation  of  the  MTL-STD-1553  multiplex  bus  standard  is 
an  obvious  success  story.  Major  weapon  system  designs  like  the  F- 1 6  and  the  B-l  broadly 
used  this  standard  definition  of  multiplex  signal  Interfaces  and  protocols.  Even 
cross-service  standardization  has  occurred  through  the  Navy's  commitment  to  MIL-STD-1553 
on  their  F-18  program. 

We  have  and  are  now  implementing  even  more  interfacing  types  of  standards,  such  as 
the  MIL-STD-1750  instruction  set  for  avionics  computers,  the  Ada  Higher  Order  Language 
(HOL)  ,  specified  by  MIL-STD- 1 8 1 5 ,  for  avionics  Operational  Flight  Programs  (OFP)  ,  and 
the  High  Speed  Data  Bus  standardization  activity  currently  underway.  Note  that  these 
are  not  "pure"  interface  standards,  but  begin  to  impinge  on  the  area  of  system 
architecture,  both  from  a  hardware  and  software  sense.  Similar  efforts  arc  going  on  in 
the  area  of  32-bit  micro-processors,  an  especially  urgent  task,  since  these  devices  may 
be  pervasive  in  all  of  our  systems  in  the  near  future  to  support  such  rapidly  developing 
disciplines  as  artificial  intelligence.  But  things  start  to  get  interesting  when  we 
move  out  of  the  area  of  simple  Interface  standards  into  the  world  of  system  integration 
-  when  we  talk  not  only  of  system  interfaces  but  of  system  topology.  Included  in  this 
level  of  system  architectural  considerations  are  concepts  which  have  evolved  from  the 
Digital  Avionics  Information  System  (DAIS)  program  through  the  PAVE  PILLAR  program  and 
are  projected  for  the  PAVE  PACE  program. 

ERA  OF  THE  1970s 


The  decade  of  the  seventies  was  marked  by  a  rapid  development  in  digital 
technology.  Integrated  circuit  technology  evolved  from  the  7400/5400  dual-inline 
packages  (DIP)  to  the  early  rud 1 mt .. t a ry  designs  for  bit-slice  and  microprocessor  on  a 
chip.  Data  communication  evolved  from  point-to-point  connection  to  multiple  device 
Interfaces  on  a  single/dual  redundant  multiplex  data  bus.  This  increased  use  of  digital 
technology  also  permitted  an  increase  in  programming  capability  and  assembly  language 
programming  began  to  "give  way"  to  the  use  of  Higher  Order  Languages  (HOLs)  6ueh  as 
JOVIAL  and  FORTRAN.  Likewise,  display  technology  and  the  use  of  programmable  displays 
began  to  take  place  with  the  development  of  the  "all  glass  cockpit"  concept. 
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DAIS 


The  Digital  Avionics  Information  System  was  formulated  specifically  to  address  the 
System  Architecture  issues. 

The  Digital  Avionics  Information  System  (DAIS)  has  been  characterized  as  a  system 
architecture  which  can  be  applied  and  configured  for  a  broad  class  of  avionic 
applications  and  missions  utilizing  digital  technology  to  reduce  life  cycle  costs  bv 
defining  and  developing  hardware  and  software  core  elements  and  standardized  interfaces 
which  can  be  configured  and  applied  to  many  aircraft. 

The  DAIS  approach  reflected  a  total  system  concept  rather  than  a  functional 
subsystem  or  hardware  oriented  system.  For  example,  a  "navigation  sub-system"  in  DAIS 
did  not  refer  to  a  dedicated  aet  of  hardware  and  software  which  performed  only  the 
navigation  function.  DAIS  architecture  and  elements  were  not  dedicated  to  any  one  of 
several  avionic  functions,  but  used  to  perform  many  of  the  avionic  functions  with  the 
avionic  sensors  and  subsystems.  The  DAIS  concept,  therefore,  proposed  that  the 
processing,  information  transfer,  and  the  control  and  display  functions  be  common  and 
service  the  avionic  application  functional  areas  on  an  Integrated  basis.  The  DAIS 
system  architecture  consisted  of  hardware  and  software  core  elements  and  standard 
interfaces  which  could  be  structured  for  various  avionics  configurations.  The 
architecture  consisted  of  processors  communicating  with  each  other  and  other  system 
elements  (acusors,  subsystems,  weapen  stations,  controls  and  displays'  through  a 
standardized  multiplex  data  bus.  Application-Independent  executive  software  allowed 
adaptability  of  the  architecture  as  well  as  performing  system  control.  Additional  key 
support  software  ’eoents  provided  the  tools  for  development,  integration,  and  test  of 
the  core  elements  -or  a  specific  application.  The  basic  attributes  of  the  DAIS  system 
which  supported  these  system  characteristics  include  flexibility,  ease  of  use,  ease  of 
modification,  and  portability. 

SYSTEM  ARCHITECTURE  OVERVIEW 

The  DAIS  architecture  consisted  of  federated  processors  communicating  with  each 
other  and  the  other  system  elements  (sensors,  weapons,  and  controls  and  displays) 
through  a  standardized  multiplex  data  bus.  This  standardized  multiplex  data  bus 
provided  dual  redundant  information  paths  between  the  system  resources  (each  computer 
and  other  system  elements).  Centralized  system  single-point  control  was  performed  by  a 
processor  resident  software  executive  that  could  be  relocated  for  redundancy. 

Application  software  was  structured  to  provide  modularity,  reliability,  and 
transferability.  This  system  architecture  was  flexible  to  accommodate  a  wide  variety  of 
avionics  configurations,  missions,  and  sensors,  and  provide  redundancy  to  improve 
availability  and  accommodate  changes  in  technology. 

The  basic  elements  of  the  DAIS  architecture  which  can  be  restructured  for  various 
aircraft  avionic  configurations  were  called  DAIS  core  elements  (or  building  blocks)  and 
were  composed  of  the  DAIS  multiplex  (bus  controllers,  remote  terminals,  and  data  buses), 
DAIS  pro  essors  (with  an  associated  memory),  DAIS  mission  software,  and  DAIS  controls 
and  displays  as  shown  in  Figure  1.  Additional  elements  were  the  support  software 
elements,  namely  the  JOVIAL  Compiler  (J73),  and  Partitioning,  Analyzing  and  Linkage 
Editing  Facility  (PALEFAC).  Sensors,  weapons,  and  other  subsystems  were  selected  as 
required  for  the  particular  mission  and  connected  to  the  interface  modules  of  the  Remote 
Terminals  of  the  multiplex  system  or  connected  directly  to  the  multiplex  bus  if  the 
subsystem  was  compatible  with  the  bus  protocol. 

The  mission  software  or  Operational  Flight  Program  (OFP)  resided  in  the  memory  of 
the  DAIS  processors.  The  mission  software  was  structured  in  a  modular  form  to  allow 
easy  mission-to-mission  sensor /weapons  changes,  provide  flexibility  for  major 
modifications,  and  provide  transferability  of  portions  of  the  software  to  other  aircraft 
applications.  The  OFP  was  partitioned  into  the  executive  software  and  the  application 
software.  The  latter  was  modularly  separable  into  the  mission  avionic  functional 
capabilities  such  as  navigation,  guidance,  weapon  delivery,  connun ica t ion ,  vehicle 
defense,  target  track  and  acquisition,  subsystem  management,  stores  management, 
autopilot,  and  pilot  interface.  The  OFP  application  software  alao  supported  the 
on-board  functional  test  capability.  In  addition,  each  processor  contained  a  ROM 
program  to  control  the  start-up  (cold  start)  and  load  of  the  OFP  from  the  system  mass 
memory . 

INFORMATION  TRANSFER  SYSTEM 

The  DAIS  multiplex  system  provided  information  transfer  between  the  elements  within 
the  system.  Including  DAIS  processors,  controls  and  displays,  and  other  subsystems.  It 
consisted  of  the  bus  controller  interface  unit  (BCIU)  ,  remote  terminal  units  (RT)  ,  and 
the  multiplex  cable  assembly  (data  bus).  The  elements  all  were  designed  in  conformance 
with  what  was  later  to  be  MIL-STD- 1553B . 

The  system  was  a  time  division  multiplex  (TDM)  data  bus  with  a  command /response 
protocol  having  one  BCIU  controlling  the  bus  traffic  at  any  given  time.  Each  multiplex 
cable  assembly  consisted  of  a  twisted,  shielded  wire  pair.  The  information  transfer  on 
the  bus  consisted  of  messages  composed  of  command,  data,  and  status  words.  The 
information  transfer  consisted  of  three  modes:  bus  controller  to  terminal,  terminal  to 
controller,  and  terminal  to  terminal  transfer. 
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The  BCiU  was  the  Interface  between  a  processor  and  two  data  buses  and  operated  in 
either  of  two  modes:  master  or  remote.  In  master  mode,  the  BCIU  operated  under  control 
of  the  Master  Executive,  issued  all  bus  commands,  and  received  all  status  words.  In  the 
remote  mode,  the  BCIU  monitored  both  buses  for  command  words  and  responded  to  valid 
commands  containing  its  own  address,  provided  transfer  of  data  in  both  directions 
between  the  processor  and  either  of  two  data  buses,  provided  status  replies  on  the 
appropriate  data  bus  in  response  to  command  (and  special  internal  operations),  and 
interrupted  the  associated  processor  upon  receipt  of  certain  mode  commands  or  detection 
of  exception  conditions. 


The  remote  terminal  (RT)  provided  the  interface  between  the  subsystem  and  the  two 
data  buses.  The  RT  transferred  data  in  both  directions  between  the  multiplex  bus  and 
subsystem  via  the  interface  modules,  based  upon  commands  received  from  either  data  bus, 
and  provided  status  replies  on  the  appropriate  bus  in  response  to  commands.  The  RT 
performed  special  operations  upon  receipt  of  a  mode  command.  The  RT  was  composed  of  a 
Multiplex  Terminal  Unit  (MTU),  Timing  and  Control  Unit  (TCU)  ,  and  Interface  Modules 
(tM).  The  Multiplex  Terminal  Unit  (MTU)  interfaced  to  the  data  bus,  and  transmitted  and 
received  information  between  the  data  bus  and  the  Timing  ar.d  Control  Unit  (TCU),  under 
control  of  the  TCU.  The  Timing  and  Control  Unit  (TCU)  performed  all  of  the  timing, 
control,  buffering,  decoding  and  checking  required  to  receive  information  from  the  data 
bus  and  transfer  that  information  as  outputs  from  the  RT ,  as  well  as  to  accept  inputs  to 
the  RT .  The  Interface  Modules  (IM)  converted  the  data  to  the  appropriate  interface 
signal  required  by  the  subsystem.  Any  RT  was  capable  uf  handling  several  signal 
interface  tvpes  in  various  mixes  and  numbers. 


PROCESSING  SYSTEM 


The  DAIS  processors  were  general  purpose  digital  computers  of  the  type  normally 
referred  to  as  mini-computers.  They  were  specially  engineered  for  airborne  use  and 
implemented  the  MIL-STD-1750  instruction  set  architecture  (TSA).  Operational  features 
included  a  vectored  priority  interrupt  system  interval  timers,  and  floating  point 
arithmetic.  All  memory  was  directly  addressable.  Indexing  as  well  as  single  level 
indirect  addressing  was  available.  A  small  read  only  memory  (ROM)  was  enabled  during 
the  start-up  sequence.  A  separate  port  to  memory  was  provided  for  the  BCIU  via  a  direct 
memory  access  (DMA)  channel.  In  a  federated  processor  con f igu ra t i on  each  processor/RCIU 
could  only  address  its  own  memory  unit.  Functionally,  the  BCIU  was  viewed  as  an 
extension  of  the  processors  input/output  capability,  very  similar  to  the  high  speed  DMA 
channels  available  on  many  mini-computers.  The  integration  of  the  BCIU  into  the 
processor  box  was  later  accomplished  with  no  external  functional  changes.  Ocher 
elements  attached  to  the  bus  saw  no  difference  In  the  operating  characteristics  of  this 
integrated  unit  as  compared  to  the  separate  processor  and  BCIU. 

EXECUTIVE  SOFTWARE 

The  executive  was  organized  into  the  master  executive  and  the  local  executive.  Each 
processor  contained  a  local  executive;  the  master  processor  also  contained  the  master 
executive. 

a.  Master  Executive  -  The  master  executive  software  performed  the  following 
functions : 

1.  Bus  Control  -  Allocated  time  segments  on  data  bus  for  synchronous 
communication  and  for  asynchronous  messages. 

2.  Systems  Error  Management  -  Monitored  and  analyzed  errors  relative  to  the 
operation  of  the  processors  and  data  bus  communications ,  and  provided  control  for  error 
recovery . 


3.  Configuration  Management  -  Initialized  multiple  computer  system  at 
start-up  and  after  severe  system  errors. 

4.  Mass  Memory  Management  -  Provided  for  the  retrieval  of  information  rrotn 
mass  memory. 

5.  Monitor  Management  -  Provided  for  monitoring  of  the  master  processor  by 
the  monitor  processor. 

b.  Local  Executive  -  The  local  executive  software  performed  the  following 
functions  . 


1.  Task  State  Control  -  Used  a  task  table  to  activate  and  deactivate  periodic 
or  non-periodic  tasks  when  appropriate  conditions  were  met.  These  conditions  were  based 
on  a  logical  setting  of  real-time  events. 

2.  Event  Control  -  Used  a  table  of  real-time  events  to  communicate  conditions 
signalled  between  processes  whether  In  the  same  or  different  processors. 

3.  Data  Control  -  Guaranteed  interlocks  between  shared  data,  provided 
mechanism  for  transmission  and  reception  of  data  over  the  multiplex  data  bus. 


4  .  CPU  Fresh  Start,  Restart  -  Used  to  initialize  CPU  ,  to  recover  from 
transient  failures,  and  to  perform  self-test. 

CONTROLS  AND  DISPLAYS 

The  DAIS  controls  and  displays  were  an  integrated  set  of  state-of- the-ar t  control 
and  display  equipment  incorporating  the  features  of  flexibility  to  accommodate  changes 
In  control  and  display  equipment,  redundancy  where  the  CRT  displays  could  serve  as 
backup  to  each  other,  and  an  efficient  design  for  system  management  by  one  pilot.  The 
units  of  the  DAIS  controls  and  displays  Included: 

Modular  Programmable  Display  Generators 

Display  Switch/Memory  Units 

Integrated  Multi- Function  Keyboards 

Data  Entry  Keyboards 

Multi-Function  Keyboards 

Master  Model  Panel 

Multi-Purpose  Displays 

Sensor  Controller  Unit 

Head— Up  Display 

Armament  Panel 

Processor  Control  Panel 

REDUNDANCY 

DAIS  provided  redundancy  in  the  system  architecture  which  could  be  employed  to 
provide  backup  and  recovery  to  complete  mission  functions  in  spite  of  hardware  failure. 
The  areas  which  could  be  used  for  redundancy  were: 

a.  Dual  redundant  data  bus  including  redundant  bus  interface  modules  in  the  BCTU 
and  RT  . 

b.  System  could  employ  dual  redundant  RTs  for  a  specific  subsystem. 

c.  Multi-Function  Keyboard  and  associated  Data  Entr«  Keyboard  could  be  used  as  a 
backup  to  the  Integrated  Multi-Function  Keyboard  ana  associated  Data  Entry  Keyboard. 

d.  Raster  displays  could  serve  as  backup  to  each  other. 

e.  A  processor /BC1U  could  be  designated  as  monitor,  serve  as  backup  to  the  master 
processor/BCIU. 

ARCHITECTURAL  FVOLUT TON 

As  a  result  of  the  DAIS  program,  standardization  was  actively  pursued  In  the 
multiplex  arena  (MIL-STD- 1 5 5 38) ,  in  the  Higher  Order  Language  field  (Ml L-STD- 1 5 P °B )  and 
in  the  avionics  processor  instruction  set  (MIL-STD- l  750A) .  However,  in  order  to  meet 
the  goals  of  true  transportability  (both  hardware  and  software)  it  is  necessary  to 
pursue  further  standardization  efforrs  in  the  areas  of  System  level  Control  Procedures, 
Multiplex  B u 8  Protocol,  Executive  Software  Function  and  Application/Execut i ve  Software 
Interfaces.  In  addition,  the  advent  of  highly  integrated  subsystems  and  the  evolving 
requirements  for  system  level  capabilities  have  Indicated  the  need  for  advancements  in 
the  basic  architecture.  These  requirements  deal  with  multiple  multiplex  bus  structures. 
Increased  system  information  processing  and  distribution  capacities,  improved  fault 
detection,  isolation  and  tolerance,  and  improved  ability  to  provide  system  functions 
under  degraded  architectural  conditions.  In  older  to  meet  these  objectives,  the 
technologies  in  each  area  have  beer  pursued  (bus  structures,  processing,  executive 
software,  etc.),  snd  the  overall  system  architecture  tins  been  refined  to  accommodate 
these  new  capabilities.  This  is  the  subject  for  the  decade  of  the  eighties. 

ERA  OF  THE  19fi0s 

The  decade  of  the  eighties  showed  that  use  of  advanced  electronics  has  given  modern 
combat  aircraft  phenomenal  levels  of  performance,  hut  at  a  stiff  price  in  Initial  cost, 
maintenance  workload  and  aircraft  ava i 1 ab i 1  i ty .  Hence,  aircraft  design  is  shifting  to 
give  equal  emphasis  on  performance,  affordability,  maintainability,  and  reliability  in 
the  development  nf  avionic  systems. 

With  the  adoption  of  MIL-STD- 1 55 3B ,  Aircraft  Internal  Time  Division  Command/ 
Response  Multiplex  Data  Bus,  some  of  the  newer  U.S.  Air  Force  strategic  and  tactical 
aircraft  have  begun  the  task  of  integrating  beyond  the  subsystem  level.  However,  even 
these  i.ewcr  system  integration  activities  have  addressed  only  the  basic  avionics 
functions  of  navigation,  weapon  delivery,  communication,  and  to  some  extent,  controls 
end  displays.  Analysis  of  a  current  tactical  aircraft  shows  that  the  avionics  suite 
consists  of  approximately  58  line  replaceable  units  with  437  different  sub-assembly 
spare  types.  The  1553  data  bus  and  dedicated  cables  alone  require  254  harnesses  to 
connect  the  external  line  replaceable  units.  The  combined  number  of  Internal  and 
external  Interconnects  explodes  to  more  than  fib, 600  connections.  Forty  percent  of  the 
maintenance  actions  on  the  flight  line  are  concerned  with  these  cables  and  connectors. 
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Analysts  shows  that  by  applying  high  speed  fiber  optic  multiplexing  and  Very  High 
Speed  Integrated  Circuits  (VHSIC)  technologies,  the  number  of  cables  and  connectors  can 
be  reduced  by  as  much  as  thirty-five  percent.  However,  this  does  not  imply  that  one  can 
just  insert  these  technologies  and  receive  the  improvements.  One  must  structure  or 
partition  the  technologies  into  a  system  architecture  which  will  permit  maintenance 
personnel  to  easily  isolate  faults  and  to  replace  failed  avionics  components.  Also, 
mission  analysis  has  shown  that  the  system  architecture  must  be  flexible  enough  to 
support  air-to-air  and  air-to-ground  mission  requirements.  This  leads  one  to  conclude 
that  the  system  architecture  must  adapt  during  the  life  time  of  the  system  to  constant 
changes  and  new  mission  requirements . 

It  follows  then  that  the  hardware  and  software  which  form  the  system  architecture 
must  have  a  modular  basis  which  will  permit  the  maintenance  personnel  to  remove  and 
replace  the  components,  yet  allow  system  designers  to  adapt  the  avionics  suite  to  new 
requirtmentR.  PAVE  PILLAR  was  created  to  solve  these  problems. 

PAVE  PILLAR 


The  trend  tn  avionics  system  design  is  to  increase  system  integration  thereby 
improving  system  accuracy,  increasing  system  immunity  to  failures,  and  decreasing  system 
reliance  on  multiple  redundant  sensors.  This  design  philosophy  which  permits  resources 
to  he  shared  across  subsystems  requires  <*  highly  coupled  system-wide  management  and 
control  program  (operating  system)  supported  by  a  wide  band  data  distribution  network, 
high  speed  processor®,  *,ud  extensive  mass  memory.  The  ability  to  consider  integration 
of  this  magnitude  is  dependent  on  recent  advances  in  micro-electronics  technology,  most 
notably  the  advent  of  VHSIC  technology. 

The  PAVE  PILLAR  avionics  architecture  is  functionally  divided  into  three  distinct 
areas  : 


Mission  Management 
Sensor  Management 
Vehicle  Management 

The  three  areas  define  the  enclosing  boundaries  for  resource  sharing,  sparing,  and 
subst itut ion .  Unique  characteristics  of  each  of  these  areas  preclude  the  utilization  of 
resources  across  areas  for  the  purpose  of  function  recovery  or  reconfiguration.  This 
dees  not  imply  that  the  areas  do  not  contain  many  common  hardware  elements,  but  that  the 
organization,  connectivity,  and  control  of  these  components  restrict  their  practical  use 
in  functional  system-wide  reassignment.  Each  of  the  three  areas  have  associated  with 
them  a  logical  processor  type  and  varying  interface  requirements.  Figure  2  illustrates 
the  top-level  organization  of  the  PAVE  PILLAR  avionics  architecture,  system  elements  are 
built  from  a  set  of  common  modules  supporting  programmable  processing,  I/O,  and  memory 
storage  functions.  The  interfaces  between  system  elements  are  standard  high  speed  time 
division  multiplex  buses  and  data  links,  all  utilizing  fiber  optics  technology. 

MISSION  MANAGEMENT  AREA 

The  Mission  Management  area  consists  of  Mission  Data  Processors,  Mission  Avionics 
Multiplex  Bus,  Block  Transfer  Multiplex  Bus,  system  Mass  Memory,  Stores  Management 
System,  and  a  collection  of  interfaces  to  the  Mission  Avionics  Bus.  This  area  provides 
the  resources  to  perform  the  mission  and  system  management  functions  such  as  fire 
control,  target  acquisition,  navigation  management,  defense  management,  stores 
management,  TF/TA/OA  functions,  and  crew  station  management.  The  Mission  Management 
Area  contains  identically  configured  Mission  Data  Processors  all  connected  to  the 
Mission  Avionics  Multiplex  Bus  and  loadable  from  the  System  Mass  Memory  via  the  Block 
Transfer  Multiplex  Bus.  All  Mission  Processing  control  and  data  exchange  outside  of 
leading  operations  is  performed  using  the  Mission  Avionics  Multiplex  Bus.  The  Mission 
Management  Area  controls  Job  assignments  for  the  Signal  Processors  and  determines  the 
connection  paths  from  Signal  Processors  (such  as  target  tracks,  CNI  reception  results, 
threat  descriptions)  and  modlng  and  control  data  is  provided  back  to  both  the  Signal 
Processors  and  the  sensor  front  ends. 

The  Mission  Management  Area  also  Interfaces  with  the  Vehicle  Management  Area  to 
receive  navigation  state  information  and  to  supply  route  and  trajectory  commands.  Ocher 
interfaces  are  to  cockpit  mul t i- f unc t ion  switches.  Stores  Management  System,  and 
miscellaneous  avionics  control  devices  not  directly  interfaced  to  the  Mission  Avionics 
Bur  (he lmet -moun ted  sight,  voice  recognition  system,  data  recorder s / reader s) .  The 
Mission  Management  Area  collects  the  health  and  status  of  all  core  elements  and 
sensor /subsy s tern  components  for  maintenance  history  and  to  maintain  mission  functional 
capability. 

SENSOR  MANAGEMENT  AREA 

The  Sensor  Management  area  consists  of  a  set  of  common  Signal  Processors,  t  sensor 
data  distribution  network,  a  sensor  control  network,  a  data  exchange  network,  and  a 
video  distribution  system.  The  sensor  management  area  provides  the  signal  processing 
functions  and  Interfaces  necessary  to  convert  conditioned  data  from  multiple  sensors  via 
a  sensor  network  into  processed  information  suitable  for  distribution  to  other  avionics 
systems.  The  sensor  management  area  accepts  encrypted  data  from  a  TRANSEC /COMSEC 
cont ro Her ( s )  and  processes  the  data  for  transmission.  This  area  also  distributes 
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processed  digital  video  to  crew  displays  and  distributes  sensor  control  commands  to 
sensors  via  a  sensor  control  network.  Signal  Processor  task  assignment,  sensor  data 
distribution  network  control,  and  Signal  Processor  resource  reconfiguration  is  managed 
by  the  Mission  Data  Processors. 

VEHICLE  MANAGEMENT  AREA 

The  Vehicle  Management  System  (VMS)  is  an  independent  subsystem  supporting  the 
fundamental  flight  and  airframe  related  control  functions.  The  VMS  Management  area  Is 
physically  isolated  from  the  rest  of  the  architecture  for  safety  of  flight  reasons  and 
contains  a  higher  degree  of  physical  redundancy,  usable  only  within  the  VMS  area.  The 
VMS  management  area  contains  VMS  Data  Processors,  Controls/Displays  interfaces,  Plight 
Sensor/Actuator  interfaces.  Electrical  Power  Control  interfaces.  Engine  Control 
interfaces,  and  Utility  Systems  interfaces.  The  VMS  Data  Processor  Is  essentially 
identical  to  the  Mission  Data  Processor  except  for  memory  configuration,  multiplex  bus 
interfaces,  and  reconfiguration  methods.  The  VMS  Data  Processor  has  Read  Only  Memory 
for  all  program  storage  and  does  not  perform  any  program  loading.  The  VMS  Data 
Processor  also  has  six  High  Speed  Bus  interfaces.  Two  dual  redundant  interfaces  to  the 
Mission  Avionics  Multiplex  Bus  and  four  simultaneously  active  bus  interfaces  to  the  VMS 
Multiplex  Bus.  Each  VMS  Data  Processor  contains  the  entire  program  load  to  perform  all 
VMS  functions.  Reconfiguration  is  accomplished  by  activating  dormant  tasks  in  available 
spare  VMS  Data  Processor  resources.  The  flight  essential  nature  of  VMS  processing 
necessitates  a  very  high  degree  of  functional  reliability  ( Fa i 1 -Op /Fa i 1-Op /Fa i 1-S a f e ) . 
This  is  accomplished  by  physical  quad  redundancy  of  sensors,  buses,  processors,  and 
actuators  in  the  VMS  processing  area.  The  partitioning  of  processing  functions  among 
VMS  Data  Processors  retains  the  quad  redundant,  simultaneously  active  characteristic  of 
the  VMS  area . 

SYSTEM  CONTROL 

Control  of  the  core  processing  system  is  provided  by  a  distributed  software 
architecture  providing  for  commonality  of  control  software  across  the  mission 
processors,  flight  control  processors,  and  signal  processors.  Major  control  functions 
inc lude  : 

-  Initialization  and  system  start-up  and  restart. 

-  Assignment  of  application  software  task  to  processing  resources  (software 
configuration  and  reconfiguration  computing  resources  management). 

-  Sequencing  and  synchronization  of  related  software  tasks. 

-  Management  of  sensor  and  other  device  resources  with  respect  to  mission 
objectives,  mode  and  task  management,  and  software  parameters. 

-  Interpretation  of  response  to,  and  integration  of,  human  control  into  the  svstem 
functionality. 

-  Collection,  maintenance,  and  reporting  of  system  hardware  and  software  status, 
and  operational  functionality, 

-  Response  to  hardware  and  software  failure  detection  to  preserve  mission 
effect iveness . 

-  Flight  control  change  management  and  response. 

-  Reintegration  of  recovered  hardware  or  software  functions. 

-  Assurance  of  a  distributed  data  base  consistency  and  integrity,  management  of 
access  to  that  shared  data. 

-  Preservation  and  collection  of  data  required  for  continuity  of  system 
functionality  across  failure  recovery  points. 

-  Management  of  communications  access  to  ensure  optimal  use  of  communication 
resources  and  correct  addressing  of  data  messages. 

-  Assurance  of  the  security  of  classified  data. 

The  operating  system  is  partitioned  into  three  elements:  (1)  the  kernel  executive  which 
provides  those  functions  common  to  all  processors,  (2)  the  distributed  executive  which 
provides  for  decentralized  system  control  in  each  processor,  (3)  system  executive  which 
provides  the  monitoring  of  system  state  and  reconfiguration  based  on  mission 
requirements  and  detected  system  failures.  Figure  3  depicts  the  in  ter rela t ionah ip  of 
the  three  elements. 

OPERATIONAL  CONCEPT 

The  PAVE  PILLAR  architectural  concept  was  developed  to  support  aircraft  operations 
from  deployed  locations  with  a  minimum  of  support.  This  architecture  supports  the 
resource  sharing  of  core  data  and  signal  processing  resources  and  is  constructed  of  a 


5-9 


FUNCTIONAL  PARTITIONING  OF  SYSTEM  SOFTWARE 


_  >  DIRECT  INTERFACES  IN  f VERY  PROCESSOR 

r _ LOGICAL  (INDIRECT)  INTERFACES  .  APPLICATIONS  FUNCTIONS 

C - V  vu  KERNEL  EXECUTIVE  PRESENT  IN  TWO  PROCESSORS 


APPLICATIONS  FUNCTIONS  ABU  TO 


EXECUTE  IN  ANY  PROCESSOR 


Figure  3 


VHSK  CHIP  SET 

anma  «*»« 


COMMON  MODULE  FAMILY 

KCIMIMMt  KCIMISCMM  IJ5MMU  •*«  MU1HU  UttlOt  IWItOUTU 

mass*  mass*  mass*  ***r  *u»m  "ttwwt  «•*» 


SYSTEMS  APPLICATIONS 


■umuTW 


Figure  4 


5-10 


set  of  common  modules  that  specifically  support  a  two-level  maintenance  concept.  This 
architecture  supports  high  degrees  of  systems  availability  and  reliability.  This  Is 
accomplished  through  the  application  of  spare  signal  and  data  processing  resources  at 
the  system  level  so  that  backup  services  are  provided  when  the  primary  sources  fail.  In 
addition,  the  architecture  supports  graceful  degradation  in  that  when  spare  resources 
are  exhausted  remaining  resources  can  be  assigned  to  the  highest  priority  functions  on  a 
mission  basis. 

COMMON  MODULES 

The  PAVE  PILLAR  architecture  is  physically  comprised  of  a  number  of  "building 
blocks"  called  common  modules.  A  common  module  is  sized  to  contain  the  circuitry  to 
perform  a  complete  digital  processing  function  including  Interface  control  and  health 
diagnosis.  The  approach  for  PAVE  PTI.I.AR  is  to  develop  common  modules  from  a  limited 
VHSIC  chip  set  and  then  develop  systems /subsystems  which  utilize  the  common  modules. 

The  exact  composition  of  the  VHSIC  chip  set  will  depend  on  the  evolution  of  that 
technology  prog  ram , wh i 1 e  the  members  of  the  common  module  family  will  he  subject  to  PAVE 
PILLAR  avionic  system  design  considerations. 

A  number  of  common  modules  can  be  built  tip  from  a  family  of  VHSIC  chips  which,  in 
turn,  can  be  grouped  to  form  the  basis  for  any  one  of  the  avionics  subsystems  depicted 
in  Figure  4.  Certain  non-common  modules  will  undoubtedly  be  required  lor  some  specific 
subsystem  implementation;  however,  the  reduction  in  numbers  of  spares  types  required  as 
a  result  of  common  module  usage  will  provide  a  significant  cost  and  effectiveness 
improvement . 

The  Avionics  Laboratory  has  undertaken  the  design  and  development  of  two  common 
module  sets:  the  VHSTC  1750A  Data  Pioressor  and  the  VHSIC  Common  Signal  Processor. 

These  modules  are  being  designed  with  stringent  requ  i  remen t s  for  both  extremely  low 
failure  rates  and  high  fault  detection  and  fault  isolation  capabilities.  Fault 
isolation  to  the  single  module  level  will  be  accomplished  by  on-board  Built-in-Test 
(BIT)  circuitry  at  the  chip  level  and  mu  1 1 i - 1 i e red  self  test  software.  Th<*  use  of  a 
nodular  concept  will  permit  the  maintenance  personnel  to  perform  on-hoard  diagnosis  and 
replacement  of  the  avionics  at  the  module  level  with  no  auxiliary  ground  equipment. 

This  capability  then  leads  one  to  conclude  that  a  two-level  avionics  maintenance 
concept  might  be  realizeable.  Figure  5  shows  the  impact  of  various  maintenance 
concepts.  The  current  three-level  maintenance  approach  consists  of  flight  line, 

Avionics  Intermediate  Shop,  and  depot/factcry  diagnosis  and  repair.  To  illustrate  the 
benefits  of  changing  from  a  three-level  to  a  two-level  maintenance  concept,  an  in-heuso 
study  to  examine  the  relative  life  cycle  cost  of  several  combinations  of  maintenance 
concepts  and  technology  integration  was  conducted.  As  shown  here,  the  costs  consist  «>f 
operations  arid  support  plus  the  Avionics  Intermediate  Shop  and  spare  parts  to  suppoi t 
1000  aircraft  for  20  years  at  a  flying  rate  of  300  flight  ••ours  per  aircraft  per  yv«ir. 
All  costs  are  stated  in  1984  dollars.  The  first  column  r  esents  today's  technology  - 
F-16  A/B  -  utilizing  the  standard  three-level  maintenance  with  removal  /  replacement  of 
LRUs  at  the  flight  line.  In  column  B,  the  three-level  maintenance  concept  is  retained 
and  LRUs  are  still  used,  but  VHSIC  Technology  has  been  incorporated  and  a  fault  tolerant 
design  through  extensive  bui 1 t - in- t e s t  has  been  Introduced.  These  steps  reduce  our  cost 
for  operating  and  maintaining  the  1000  aircraft  fleet  by  nearly  20%.  In  the  next  step, 
where  the  Avionics  Intermediate  Shop  is  eliminated  and  everything  else  is  kept  the  sdme 
as  B,  there  is  a  further  reduction  in  cost  of  over  $200M.  Finally,  introduction  of 
standard  modules  provides  a  further  reduction  In  cost  to  approximately  one-half  of  the 
current  ownership  bill.  While  these  numbers  are  not  hard  and  fast  they  do  provide  an 
indication  of  the  sizeable  cost  g a  ins  which  can  be  realized  through  the  application  of 
PAVE  PILLAR  technologies. 

TECHNOLOGY  TRANSPARENCY 

The  building  block  approach  espoused  in  this  section  permits  not  only  the  initial 
development  of  a  highly  flexible  avionics  suite,  ^ut  also  the  continued  development  and 
Integration  of  Pre-Planned  Product  Improvement  (P  I).  This  is  accomplished  within  the 
architecture  by  the  concept  of  standard  data  buses  (Parallel  Interface  (PI),  Test  and 
Maintenance  (TM)  ,  High  Speed  Data  Bus  (HSDB))  and  networks  (SDUH,  VDDN  ,  DFN,  D^ta  Flow 
Network).  This  concept  is  Implemented  by  Form,  Fit,  Function  and  Interface  (F'l), 
specifications  for  each  module  type  thereby  permitting  different  designs  by  vendor  for 
each  module  type  and  specific  vendor  module-  design  modification  dependent  upon 
t ec bnol og  l  ca 1  imp ro vemen t s . 

Due  to  the  open  architecture,  as  new  building  Mocks  are  identified  they  can  be 
readily  integrated  into  the  avionics  system,  thus  permitting  the  performance  upgrade  to 
an  existing  aircraft  at  a  relatively  low  cost.  New  investigations  have  already  begun  in 
the  areas  of  parallel  processing,  artificial  intelligence  processing,  and  optical 
processing.  The  intent  is  to  Integrate  these  advanced  processing  elements  into  the  PAVE 
PILLAR  architecture  if/when  they  become  viable  both  operationally  and  1 og  is t i c a  1 J y . 

In  summary,  a  PAVE  PILLAR  avionics  architecture  will  result  in  dramatic 
improvements  in  availability,  mission  effectiveness,  and  cost  of  ownership.  For  reasons 
of  mobility,  logistics  cost  control,  and  austere  maintenance  of  aircraft  at  forward 
sites,  a  two-level  maintenance  concept  with  line  replaceable  modules  is  endorsed  by  the 
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PAVE  PILLAR  system.  PAVE  PILLAR  plans  to  achieve  these  benefits  and  goals  through 
advances  in  technology  and  a  systems  approach  to  avionics  integration.  PAVE  PILLAR 
expected  to  provide  the  generic  integration  approach  and  architecture  that  will  act 
the  foundation  for  avionics  development  in  next-generation  Air  Force  aircraft. 
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ERA  OP  THE  1990s 


The  decade  of  the  nineties  brings  with  it  an  avionics  technology  base  of  historic 
proportions  which  is  currently  being  sponsored  by  government  R&D  agencies.  For  example, 
work  in  microelectronics  is  yielding  processor  chips  that  can  be  driven  at  a  100 
megahertz  clock  rate.  Sophisticated  parallel  processor  networks  are  being  developed  iti 
an  attempt  to  achieve  eve**  higher  processor  speeds.  Wafer  scale  integrated  ciicuits 
have  been  built  which  could  potentially  reduce  the  size  of  large  parallel  processor 
networks  to  hand-held  units.  Researchers  are  also  developing  robust  AI  algorithms  for 
the  first  time  which  will  assist  aircrews  in  decision  making.  Neural  network  theory  and 
actual  device  construction  is  making  rapid  progress  and  adaptive  learning  systems  on 
aircraft  can  now  be  realistically  projected. 

Advanced  packaging  and  cooling  technologies  are  under  development  which  will  allow 
us  to  dramatically  reduce  circuit  connections  and  improve  thermal  management  to  enhance 
reliability.  Also,  powerful  new  CAD/CAM  capabilities  are  under  development  that  will 
revolutionize  how  RF  and  digital  hardware  will  be  designed  and  manufactured  and  how- 
avionics  software  will  be  designed,  developed  and  supported  in  an  affordable  manner. 

If  the  above  set  of  technologies  are  properly  exploited,  matured  and  integrated 
during  the  1990s,  21st  century  avionics  will  undergo  a  change  that  will  be  as  dramatic 
as  the  introduction  of  the  transistor.  The  PAVE  PACE  initiative  is  being  planned  to 
affect  these  changes. 

With  the  2lst  century  being  only  a  decade  away,  we  now  should  be  able  to  begin 
performing  forecasts  to  answer  the  following  questions  relating  to  avionics  systems 
capabilities  in  that  time  frame:  (1)  What  new  performance  capabilities  will  early  21st 
century  avionics  enable  relative  to  improving  situation  awareness  and  crew  workload 
reduction?;  (2)  Will  we  be  able  to  finally  make  significant  improvements  in  avionics 
system  reliability?  Is  there  hope  that  new  technology  developed  during  the  90s  will 
allow  scheduled  maintenance  for  avionics?  Will  we  be  able  to  build  avionics  that  is 
expected  to  have  a  30-day  operation  with  minimal  repair  and  replacement?;  (3)  Will  we  be 
able  to  finally  curtail  the  escalating  cost  spiral  for  avionics,  particularly  develop¬ 
ment  and  support  cost?;  (A)  What  new  forms  of  functional  integration  can  we  expect  to 
see  as  a  result  of  the  new  technologies  and  the  need  to  fuse  information?;  and,  finally, 
(5)  What  types  of  avionic  system  architectures  will  be  needed  to  support  strides  in 
reliability,  performance  and  cost  savings? 

FORCES  THAT  WILL  SHAPE  THE  21ST  CENTURY  AVIONICS 

The  characteristics  of  early  2  1st  century  avionics  will  be  shaped  by  irresistible 
forces  operating  on  available  technologies.  Implications  derived  frr-m  how  these  forces 
and  constraints  will  generally  shape  future  avionic  requirements  will  be  made. 

DESIRED  OPERATIONAL  CAPABILITIES 

As  scenarios  become  more  complex,  the  quality  of  time-compressed  decisions  by  the 
aircrew  can  be  expected  to  decrease,  while  the  number  of  required  actions  will  likely 
increase  unless  proper  steps  are  taken.  Clearly,  more  inform acion  derived  from  sensors 
and  weapon  status  information  will  be  required  and  much  larger  amounts  of  exteri al  "C3I" 
data  will  come  into  the  cockpit  from  other  sources.  Given  that  the  basic  skeletal 
framework  for  acquiring  and  distributing  the  data  is  being  put  in  place  (i.e.  PAVE 
PILLAR),  the  next  step  is  to  develop  the  technology  that  translates  the  artificial  world 
of  sensors  into  an  easily  understood  world  that  can  be  exploited  by  our  human  abilitie 
This  "avionic  technology  missing  link"  is  viewed  as  pivotal  in  determining  the  future  of 
avionics.  We  must  develop  means  to  achieve  full  spherical  situation  awareness  (SA)  of 
threats,  targets  and  terrain  in  a  volume  of  space  and  time  of  interest  to  the  aircrew. 

We  must  enable  selected  automation  that  allows  the  crew’s  intend  to  be  expressed  bv 
direct,  simple  actions.  Further,  we  must  implement  "simple  to  use"  avionics  in 
extremely  complex  scenarios  that  involve  coordinated  intra-flight  netting  of  resources 
for  both  offensive  and  defensive  tactics. 

In  order  to  affect  needed  information  presentation  and  control  improvements, 
several  new  technologies  will  be  required.  These  include:  (1)  large  full  color  high 
brightness,  displays  for  "Big  Picture"  presentation  of  the  situation;  (2)  extremely  high 
speed  graphics  processors  (tens  of  MOPS)  will  be  required  to  present  real-time  panoramic 
graphical  information  for  head-down  and  helmet  mounted  displays;  (3)  the  use  of  real-time 
AI  algorithms  (and  ultimately  neural  network  implementations)  will  be  needed  to 
determine  how  information  is  to  be  presented,  provide  tactics  recommendations,  system 
health  status,  assist  in  mission  replanning,  sensor  management,  determine  pilot  intent, 
etc.  High  speed  processing  in  the  order  of  a  few  MOPs  ("simple"  Al  applications)  to  a 
few  BOPs  (complex  cooperating  expert  system)  will  be  needed;  (4)  advanced  signal 
processing  techniques  to  enable  continued  operation  across  the  RF  spectrum  in  jamming 
environments  will  require  extremely  high  speed  processing  which  could  reach  a  few  BOPs; 
(5)  "Smart"  sensors  are  needed  to  detect  and  identify  targets  and  threats.  Again, 
several  BOPs  will  be  required;  (6)  selectable  automation  of  integrated  vehicle  and 


>-13 


weapon  control  functions  will  be  necessary  in  many  situations  to  allow  pilots  tu 
concentrate  on  high  level  management  decisions  and  communicate  with  support  forces.  For 
example,  the  selected  integration  and  automation  of  flight  control,  fire  control,  engine 
control,  thrust  vector  control  and  weapons  control  may  be  highly  beneficial  in  aerial 
combat,  missile  evasion  and  low  altitude  ma n euve r  i ng- f 1  igh t  profiles.  This  integrated, 
automated  system  (which  also  would  likely  employ  AI  algorithms)  would  again  require  hign 
speed,  fault  tolerant  processing  of  the  order  of  several  tens  to  hundreds  of  MOPs;  and 
(7)  finally,  robotic  air  vehicles  (RAVs)  will  likely  make  their  presence  known  in  r. 
significant  way  during  the  early  21st  century  to  complement  manned  vehicles.  The 
authors  envision  these  vehicles  to  serve  as  a  force  multiplier  in  extremely  hazardous 
scenarios  across  the  range  of  tactical  missions.  Since  RAVs  represent  the  need  for 
massive  automation,  including  the  robust  use  of  AI ,  most  of  the  above  comments  relating 
co  the  high  speed  processing  apply  here. 

In  summary,  desired  operational  capabilities  for  the  early  21st  century  requfre 
extraordinarily  high  speed  processing.  These  speeds  are  generally  not  achievable  by  one 
or  even  a  tew  of  the  fastest  processors  we  will  have  available.  We  will  need  to  utilize 
parallel  networks  to  achieve  these  speeds.  We  will  need  to  find  a  way  to  solve  several 
problems  before  the  capabilities  cited  in  the  above  discussion  become  reality.  Some  of 
these  problems  include:  (l)  achieving  an  affordable  approach  to  the  development  and 
support  of  massive  amounts  of  numeric  and  symbolic  software;  and  (?)  packaging  tbe 
parallel  networks  into  aircraft  compatible  dimensions  while  achieving  affordable 
hardware  configurations  that  are  reliable  and  fault  tolerant.  As  challenging  as  these 
problems  appear  to  he,  there  are  technologies  under  development  that  appear  to  offer 
workable  solutions. 

COST  CONSTRAINTS 

Avionics  usually  represent  about  one-third  the  fly-awav  cost  of  a  fighter  and 
usually  a  higher  fraction  of  the  maintenance  cost.  As  missions  become  more  complex  and 
as  more  robust  suites  of  avionics  are  added,  these  fractions  will  likely  increase  unless 
fundamental  processes  are  reversed.  Cost  containment  and  even  cost  reduction  of 
avionics  is  expected  to  become  a  significant  issue  during  the  1990s.  It  is  increasingly 
apparent  that  expensive  avionics  reduce  the  number  of  aircraft  that  can  hr  afforded. 

Avionics  cost  is  justified  if  commensurate  improvements  in  survivability  and  force 
multiplication  are  realized.  Over  the  past  two  decades,  we  have  seen  dramatic, 
cost-effective  improvements  in  weapon  system  flexibility,  capability  and  survivability 
due  to  the  use  of  avionics,  particularly  programmable  computers.  These  strides  were 
enabled  by  impressive  increases  in  hardware  speed  and  significant  decreases  in  processor 
and  memory  cost.  Because  the  use  of  programmable  computers  is  so  pervasive,  the 
escalating  cost  of  software  design,  development  and  support  has  become  a  central  problem 
in  cost  containment  for  the  entire  weapon  system. 

A  software  cost  crisis  is  building.  If  it  J  s  not  contained,  fewer  capable  aircraft 
will  be  built  or  we  will  have  lets  capable  aircraft.  Strides  in  software  productivity 
have  not  begun  to  keep  pace  with  hardware  strides  despite  significant  progress  in 
software  standards  and  tools. 

For  example.  Figure  6  shows  the  dramatic  growth  of  software  costs  for  mission 
critical  Air  Force  computer  resources.  Some  observations  are:  (1)  through  1985,  most 
computing  hardware  in  the  force  structure  consisted  of  data  processors.  The  steady 
percentage  decrease  in  the  cost  of  data  processing  hardware,  in  spite  of  its  more  robust 
use  on  aircraft,  can  be  seen;  and  (2)  rising  support  software  costs  through  1985  was 
caused  by  several  factors:  (a)  a  bow-wave  effect  where  an  increasing  number  of  software 
systems  must  still  be  supported  (machine  code,  assembly  code  and  HOL);  (b)  standard¬ 
ization  of  languages  and  instruction  sets  have  helped  slow  down  the  rate  of  cost  growth 
but  has  not  been  in  place  long  enough  to  dramatically  effect  overall  costs;  and  (c) 
software  design  and  development  productivity  has  not  kept  pace  with  the  opportunities 
(and  temptations)  afforded  by  hardware  strides. 

Although  the  past  decade  has  witnessed  significant  cost  growth  In  data  processing 
software,  new  factors  are  at  work  which  could  further  escalate  software  cost  growth. 

These  new  factors  include:  (1)  steady  movement  towards  automating  aircraft 
functions  to  relieve  crew  workload  and  stress,  thereby  increasing  demands  on  data 
processing  software;  (2)  the  growth  of  programmable  signal  processing,  with  an  immense 
software  burden,  is  becoming  necessary  to  meet  complex  threat  environments;  (3)  a  trend 
towards  functional  Integration  on  aircraft  is  resulting  in  a  dramatic  increase  in 
programmable  data  and  signal  processors;  and  (4)  during  the  1990s,  real-time  machine 
intelligence  should  be  demonstrable  in  the  laboratory  in  flyable  configurations. 

Processors  executing  billions  of  opera' ions  per  second  may  be  flying  by  the  year 
2000.  Exceedingly  expensive  software  could  result.  Advanced  software  support  tools 
will  be  needed  to  help  develop  software  for  parallel  processors.  Advanced  AI,  image 
processing  and  signal  processing  algorithms  will  be  massively  large  and  complex. 

There  are  several  factors  that  must  be  considered  in  containing  processing  hardware 
and  software  cost:  (1)  we  must  adhere  to  standards  that  allow  technology  growth, 
maximize  competition  and  promote  reusability  of  designs,  design  tools  and  support 
hardware  and  software  (i.e.  computer  instruction  sets,  HOLs,  compilers,  etc.);  and  (2) 
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we  must  stress  the  replicated  use  of  common  hardware  modules  across  the  entire  force 
structure,  with  the  ultimate  goal  of  having  common  modules  across  DOD  avionics,  (3)  we 
must  make  fundamental  changes  in  the  way  software  is  designed,  developed  and  supported. 

MANPOWER  CONSTRAINTS 

The  availability  of  skilled  maintenance  personnel  in  the  Air  Force  is  another 
factor  which  will  drive  early  21st  Century  avionics.  An  Air  Force  Studies  Board  report 
investigating  the  isolation  of  faults  in  Air  Force  weapon  systems  concluded  that  there 
would  be  a  growing  demand  for  competent  Air  Force  electronics  technicians  due  to 
increasingly  complex  avionics,  increased  demand  by  the  private  sector  and  a  shrinking 
manpower  pool  among  18-24  year  old  people  in  the  U . S .  One  conclusion  of  the  report  was 
that  we  must  move  toward  decreasing  functional  specialization  at  the  flight  line.  In 
the  authors*  opinion,  manpower  constraints  will  accelerate  the  use  of  a  standard  line 
replaceable  avionic  modules  which  has  been  espoused  by  the  PAVE  PILLAR  program.  In 
addition  to  modules  for  data  and  signal  processing,  various  data  bus  and  I/O  Interface 
and  power  supply  modules,  the  module  concept  will  be  extended  to  encompass  additional 
electronic  functions  include  RF  circuitry,  displays,  gyros,  etc.  (However,  with 
different  packaging  and  cooling  designs.) 

AVIONICS  SUPPORT  ENVIRONMENT  FORCES  AND  CONSTRAINTS 

The  projected  support  environment  for  Air  Force  Avionics  around  the  year  2000  will  force 
fundamental  changes  in  electronics  design,  packaging  and  testing.  The  "Air  Force  2000 
R&M"  report  portrays  an  immensely  challenging  situation  for  the  avionics  support 
community.  The  document  states  that  vulnerability  of  our  entire  weapon  system  support 
structure  to  hostile  action  will  be  the  most  critical  support  issue  by  2000.  The  report 
emphasizes  the  need  to  plan  for  austere  support  conditions,  Dramatical  1 v  improved 
avionics  reliability  and  simplified  maintainability  with  reduced  flight  line  personnel 
are  required,  thereby  reducing  dependencies  on  the  supply  pipeline.  The  author  believes 
that  the  "R&M  2000"  scenario  implies  chat  the  following  characteristics  are  needed  for 
21st  century  avionics:  (1)  we  must  extend  the  use  of  modular  electronics  across  a  vide 
spectrum  of  avionics  applications;  (2)  the  number  of  different  module  types  must  be  kept 
to  a  minimum  to  allow  a  full  complement  of  spares  to  be  carried  on  a  small  ground-based 
vehicle;  (3)  highly  reliable  on-boarj  testing  of  circuitry  will  be  mandatory. 

Pervasive  use  of  BIT/SIT  with  AI  programs  is  expected,  along  with  more  extensive  use  of 
fault  tolerance;  the  concept  of  deferred  or  scheduled  maintenance  for  avionics  will  not’d 
to  be  accomplished,  where  graceful  degradation  concepts  are  built  into  virtually  every 
module;  and  (4)  the  reliability  of  avionics  must  be  improved  in  a  revolutionary  manner. 

SUMMARY  OF  DESIRED  21ST  CENTURY  AVIONIC  CHARACTERISTICS 

It  is  the  authors'  views  that  four  fundamental  (i.e.  non-evol ut  ionary )  changes  or 
developments  will  be  required  to  meet  the  forces  and  constraints  that  will  drive  21st- 
century  avionics.  These  changes,  along  with  proposed  goals  are: 

(1)  Pervasive  use  of  machine  intelligence  across  virtually  all  electronic 
functions  ranging  from  "smart  sensors"  to  cooperating  expert  systems. 

(2)  Parallel  processor  networks  which  will  execute  numerical  and  heuristic 
algorithms  at  speeds  10-100  times  faster  than  the  fastest  available  uniprocessors. 

(3)  Software  design  and  development  tools  that  will  allow  productivity  to  improve 
by  at  least  a  factor  of  ten  over  current  practices. 

(4)  The  use  of  advanced  materials,  packaging  and  cooling  techniques,  along  with 
fault  tolerant  techniques  that  will  enable  electronics  to  operate  for  say  a  thirty  day 
period  with  minimal  flight  time  support  . 

Two  evolutionary  trends  in  avionics  reflecting  a  continuation  of  recent  concepts 
are  also  seen.  They  are: 

(1)  an  expanded  use  of  a  standard  family  of  line  replaceable  modules  across  a 
broader  spectrum  of  avionic  applications  to  enable  flight  line  maintenance  under  austere 
cond i t ions . 

(2)  an  acceleration  of  functional  integration  and  sensor  fusion  design  concepts 
across  a  broad  array  of  electronics. 

ADVANCED  ENABLING  TECHNOLOGIES  FOR  21st  CENTURY  AVIONICS 
PARALLEL  PROCESSING 

Many  force  multiplier  improvements  in  smart  sensors,  vehicle  control,  situation 
awareness  and  crew  decision  aiding  will  be  made  possible  if  affordable,  flyable 
supercomputers  and  associated  software  can  be  developed  for  next-generation  military 
aircraft.  New  functional  architectures  will  emerge  because  dramatic  improvements  in 
processing  speed  can  be  implemented  through  tightly  coupled  networks.  Unconstrained 
system  architectures  can  be  developed  where  the  system  designer  will  have  the  capability 
to  fuse  together  needed  logical  functions  irrespective  of  previous  boundaries. 
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Several  types  of  parallel  processor  network  architectures  have  been  constructed 
under  DARPA  sponsorship  as  well  as  through  private  ventures.  Researchers  are 
programming  these  machines  to  develop  an  understanding  of  how  beet  to  match  the 
algorithmic  features  of  the  application  to  specific  architecture  features  in  order  to 
maximize  computer  network  speed  up. 

The  single  most  important  issue  in  parallel  processing  is  the  equivalent  speed  up 
gained  by  the  use  of  "n"  processors.  In  general,  a  speed  up  of  "n"  cannot  be  expected 
since  real  wer 1 d  problems  are  not  perfectly  parallel.  If  a  is  defined  as  the  fraction 
of  the  algorithm  that  can  be  parallelized,  the  relation  between  speed  up  achieved  by  r. 
processors  and  a  is  shown  in  Figure  7.  Figure  7  points  out  a  fundamental  property  of 
parallel  computation:  unless  a  is  greater  than  0.9,  parallel  networks  will  not  provide  a 
significant  speed  increase.  It  is  imperative  that  the  algorithm  be  investigated  for 
parallelism  before  proceeding  to  parallel  network  implementation.  Since  the  slope  of 
the  curves  in  Figure  7  vary  as  a  quadratic  relationship  with  n  as  a  approaches  1,  new 
algorithms  emphasizing  parallelism  and/or  the  use  of  compiler  tools  that  reformat  an 
existing  algorithm  into  its  most  robust  parallel  form  will  be  mandatory.  Given  that  an 
algorithm  lends  itself  to  parallelism,  then  its  significantly  parallel  portions  must  ve 
efficiently  mapped  onto  cue  proper  network  architecture  if  "real-time"  processing  of 
complex  algorithms  is  to  be  achieved.  The  architecture  selected  must  exhibit:  (a)  the 
proper  "grain  size"  for  each  processing  element;  (b)  highly  efficient  communications 
between  processing  e laments ;  (c)  high  speed  memory  accessibility  (particularly  for  large 

sized  applications);  (d)  good  load  balancing  for  the  processing  tasks  over  time;  and  (e) 
real-time,  fault-tolerant  operation. 

Dozens  of  different  parallel  network  architectures  are  conceivable,  each  having 
different  memory  access  approaches,  communication  schemes,  network  control  schemes,  node 
size  (i.e.  processor /memory  pair),  etc.  A  thorough  description  of  the  range  of  choices 
is  beyond  the  scope  of  this  paper.  The  interested  render  should  consult  References  3-7 
for  brief  descriptions  of  some  of  the  more  popular  parallel  architect  tires.  Both 
multiple  instruction  multiple  data  (MIMD)  and  simple  instruction  multiple  data  (SIMD) 
network  control  schemes  have  been  built.  S IMD-cont rol led  networks  have  single, 
broadcasted  instruction  streams  to  all  nodes  during  a  given  cycle.  A  third  general 
class  of  networks  is  the  systolic  array  which  is  a  STMD  machine  that  pipelines 
computations  between  several  nodes  in  a  serial  fashion. 

Figure  8  shows  a  general  comparison  of  various  network  architectures.  Note  that  a 
bus  structured  architecture,  such  as  PAVF.  PILLAR  Is  excellent  for  interfunct lunal 
integration  where  bus  latencies  do  not  present  problems.  Although  this  is  a  parallel 
architecture,  most  poralled  nets  will  consist  of  switch-based  circuits.  These  "domain 
processor  networks"  will  he  connected  to  the  PAVE  PILLAR  bus.  Such  a  concept  of 
hierarchical  or  tiered  system  networks  is  perfectly  compatible  with  PAVE  PILLAR. 

The  cost  effective  choice  of  using  .?  SIMD  or  MIND  network  architecture  depends  on 
the  characteristics  of  the  application. 

In  general,  the  SlMD-hased  network  is  preferable  when  the  algorithm  is  well 
.structured,  and  has  a  regular  pattern  of  control  for  the  cooperating  nodes.  If  the 
algirithm  displays  these  properties,  the  network  control  hardware  that  issues  the  highly 
synchronized  single  instruction  stream  can  he  shared  hy  all  nodes,  which  also  will 
result  in  simpler  software  programming.  Fxample  algorithms  that  generally  possess  these 
properties  include  matrix  calculations,  certain  types  of  artificial  intelligence 
applications  ( e . g .  semantic  networks),  image  processing  and  signal  processing. 

A  MIMD  network  architecture  will  likely  be  preferred  if  the  algorithm  control  flow 
is  highly  complex  and  data  dependent.  For  such  algorithms,  much  of  the  SIMD  network 
nodes  would  sit  idle  much  of  the  time  waiting  for  the  proper  instruction. 

Example  Ml MD-or i cn t ed  algorithms  include  certain  types  of  artificial  intelligence 
applications  (e.g.  tactics  planning,  mission  planning,  system  health  management, 
situation  assessment)  and  executive/system  control  of  complex  processing  sites. 

«•» 

It  must  also  be  observed  that  a  mixture  ot  th«*  SIMP  and  MIMD  architectures  mav  be 
the  preferred  design  for  some  ap p l  i  c a t i c n s . 

AIRBORNE  PACKAGING  OP  P  ORTUH  l  T  T  F.S 

Use  of  VIST  circuitry  applied  tr  wafer  scale  integration  and  hybrid  wafer 
Integration,  will  ultimately  lead  to  three-dimensional,  stacked  wafer  computers  to 
(irair.aticallv  reduce  weight,  volume  and  size.  Techniques  for  on-surface  1  n  t  e  r  c  miner  t  i  on 
of  processing  microcircuit  cells  are  being  developed  and  tec hnlq vies  for  interconnection 
of  stacked  wafers  in  a  "3-D"  array  are  under  development. 

The  resulting  "3-D  computer"  will  consist  of  about  90%  silicon  (as  compared  with 
1-15%  with  today's  military  processors).  Reliability  is  substantially  enhanced  hy 
deleting  the  use  of  printed  wiring  boards  with  its  thousands  of  chip-to-bonrd  solder 
connections.  Also,  total  system  speed  of  the  multi-cell  wafer  is  enhanced  due  to  th<* 
absence  of  high  capacitance  wires  which  Inhibit  chip-to-chip  high  speed  data  transfer. 
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The  early  21st  century  designer  can  seriously  contemplate  wafer-based  designs. 
Simply  stated,  a  hand-held  (e.g.  10  cm  x  5  cm)  parallel  processor  capable  of  executing 

billions  of  operations  per  second  is  reasonable  by  1995. 

In  achieving  a  "hand-held  supercomputer,"  a  few  basic  caveats  must  be  stated. 

First,  there  is  the  question  of  achieving  high  yield  of  the  cells  across  the  wafer.  The 
minimum  feature  size  (and  hence  speed)  of  Che  separate  cells  and  whether  a  monolithic  or 
hybrid  approach  should  be  used  must  be  determined.  Secondly,  and  always  very  important, 
is  the  algorithm-to-architecture  matching  problem.  There  are  two  basic  design  choices: 

(1)  use  customized,  stacked  wafer  processors  having  unique  wafers  for  every  high  speed 
parallel  network  application  on  the  aircraft,  or  (2)  use  a  family  of  wafer  modules,  and 
replicate  their  common  use  across  various  applications. 

CAN  AVIONICS  RELIABILITY  BE  DRAMATICALLY  IMPROVED? 

Achieving  high  avionics  reliahility  will  require  combined  use  of  (at  least)  the 
following : 

(1)  carefully  controlled  manufacturing  processes  with  extensive  testing 

(2)  avoidance  of  high  voltage  and  mechanical  componentry 

(3)  improved  thermal  management  to  not  only  prohibit  high-end  temperatures  from 
being  reached,  but  temperatures  cycling  needs  to  be  kept  to  a  minimum. 

(A)  a  significant  reduction  in  electrical  connections  between  chip  to  printed 
wiring  board  (PWB) ,  PWB  to  backplane  and  backplane  to  cabling/  data  buses. 

(5)  robust  use  of  fault  tolerance  for  mission  critical  functions. 

Many  exciting  technology  developments  .are  responding  to  item  (2)  above.  These 
include  the  use  of  laser  gyros,  phased-arrays  and  solid  state  RF  circuitry.  The 
accelerated  use  of  RF  micro-electronics  will  result  from  the  tri-service  MIMIC  program. 

Item  (3)  above  requires  the  application  of  advanced  technologies  which,  although 
they  are  yet  to  be  proven  across  all  of  avionics,  offer  significant  promise.  These 
technologies  include:  improved  means  to  reduce  thermal  resistance  and  stabilize 
temperature  excursions  through  the  use  of  direct  immersion  of  electronics  in  liquids, 
phase-change  cooling  and  use  of  heat  pipes. 

Items  (4)  and  (5)  can  be  accomplished  by  the  use  of  new  microelectronic  packaging 
technology  and  the  use  of  photonics.  Electronics  constructed  at  the  wafer  level  or 
using  hybrid  surface  mount  techniques  appears  to  be  required.  Interconnecting  cells 
reliably,  using  surface-mount  approaches,  will  be  the  largest  challenge  to  wafer  scale 
integration.  Figure  9  shows  a  very  preliminary  sketch  of  an  avionics  module  that 
combines  the  features  of  liquid  cooling  and  WSI,  along  with  estimates  associated  with 
module  parameters.  Although  much  work  remains  to  be  done  in  determining  how  the  packag¬ 
ing,  cooling  and  interconnections  are  to  be  accomplished  most  reliably,  the  significant 
observation  is  that  the  face  of  avionics  packaging  may  substantially  change  by  the  early 
21st  cent  ury . 

NEW  AVIONICS  DESIGN  &  DEVELOPMENT  CAPABILITIES 

In  order  to  affordably  design,  develop,  test  and  support  electronic  svstems  of  the 
future,  fundamental  changes  must  be  made.  The  resulting  new  design  and  development  era 
for  avionics  will  be  dominated  by  the  use  of  CAD/CAM  technologies  which  will  enable 
simulation,  design,  development,  testing,  and  documentation  from  the  system  to  the 
component  level. 

Figure  10  shows  an  example  of  the  general  fl ow  of  this  highly  automated  process. 
Once  requirements  are  generated,  top  level  system  network  simulations  will  be 
accomplished  to  establish  overall  functional  partitioning  and  proper  system  control 
operation.  Software  tools  will  cheo  be  used  to  ensure  the  proper  hardware/ software 
match  for  all  processing  resources,  including  parallel  networks.  These  tools  include 
simulators,  compilers,  linkers,  assemblers  and  code  generators. 

Software  application  program  development  and  support  will  be  approached  with  the 
same  hardware-oriented  philosophy  of  using  CAD  tools  and  reusable  modules.  Here, 
libraries  of  reusable  application  software  modules  are  tailored  to  fit  specific 
application  needs  (these  modules  will  be  designed  to  have  extensive  modularity  and  I/O 
flexibility).  In  order  to  further  enhance  programmer  productivity,  "fourth-generation" 
programming  techniques  will  be  employed.  Figure  11  shows  the  relative  impact  of  various 
factors  that  drive  software  development  cost  and  points  out  the  need  for  fourth 
generation  language  programming.  Note  that  whereas  the  programming  team's  experience 
with  the  language,  the  size  of  the  data  base  and  other  factors  are  very  important  cost 
drivers,  the  numbers  of  source  instructions  is  the  dominant  cost  driver.  Therefore, 
cost  will  be  substantially  reduced  if  software  modules  can  be  reused  or  modified  in  a 
simple  manner,  and  if  custom  software  can  be  developed  with  a  minimum  of  source 
instructions. 
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PROCESSING  IMPACT  OF  TECHNOLOGY  INTEGRATION 
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Figure  12  shows  an  example  of  how  the  concept  of  fourth  generation  programming  and 
reusable  software  might  be  accomplished.  Here  support  software  for  specific  functional 
areas  is  used.  This  code  translates  the  "pictorial"  commands  of  a  system  programmer  or 
functional  specialist.  The  inituitive  programmer/designer  communicates  at  a  level  most 
familiar  to  established  design  practices  (e.g.  pictorial  formats  If  a  display  generator 
is  being  programmed,  flow  graphs  for  signal  processing,  feed  back  loops /mu  1 1 i pi iers / 
gains  for  flight  controls),  etc.  Initially  reusable  application  or  executive  modules 
will  be  developed  using  these  tools.  Subsequently,  the  same  tools  will  be  used  to 
tailor  reusable  code  to  the  specific  application.  A  front-end,  Ada-based  compiler  is 
assumed,  with  loadable  machine  code  developed  using  these  four  tools.  Automated 
documentation  is  also  produced  by  the  software. 

ADVANCED  ARCHITECTURE  AND  INTEGRATION  TRENDS 

If  technology  will  allow  us  to  build  flyable  supercomputers  and  fast  switching 
networks,  how  will  system  architecture  be  affected?  Will  new  ways  of  integrating 
functions  develop,  given  that  technical  constraints  will  no  longer  he  a  serious  factor 
in  determining  how  the  system  is  partitioned?  These  two  questions  must  be  answered 
together  since  architecture  enables  integration  and  integration  drives  architecture. 

It  was  only  slightly  more  than  a  decade  ago  when  electronic  systems  began  to  be 
integrated  by  the  DAIS  program.  Loosely  coupled  offensive  and  defensive  sensors  and 
controls/displays  were  integrated  across  a  multiplex  bus,  along  with  the  bus-oriented 
integration  of  flight  controls  and  stores.  (See  Figure  1)  Here,  the  thrust  was  on 
establishing  digital  standards,  easing  integration  (e.g.  reduce  cabling)  and  reducing 
support  costs. 

PAVE  PILLAR  further  enabled  integration  within  and  across  avionic  functional 
elements.  The  PAVE  PILLAR  architecture  allows  for  improved  fault  tolerance  and 
commonality  of  line  replaceable  modules.  Three  basic  integrated  functional  areas  are 
emerging  from  this  architecture  (Figure  2).  These  areas  are:  (1)  sensor/pre-processors / 
signal  processors;  (2)  data  processing  for  system  control/reconfiguration  and  system 
level  computations;  and  (3)  vehicle  management  (flight,  propulsion,  electrical  power). 
Redundancy  of  processing  elements  and  buses  is  selectable,  based  on  system  requirements. 
This  architecture  allows  the  designer  to  select  whether  processing  and  information 
exchange  should  be  done  at  a  local  level,  as  part  of  a  functional  affinity  group  or  at 
the  mission  avionics  level. 

The  authors  believe  that  Integrated  «..finlty  groups  of  functions,  or  "met a 
functions"  will  emerge.  For  example,  an  "RF  meta-function"  would  utilize  needed 
portions  of  the  RF  spectrum  to  transmit,  receive  or  share  information  as  an  integrated 
system  (thereby  improving  situation  awareness,  stealth,  fault  tolerance  and  reliability 
of  processed  results).  Similarly,  other  met af unctions ,  shown  in  Figure  13,  are  expected 
to  emerge  in  the  areas  of  E0 ,  vehicle  conttol.crew  station  electronics  and  system 
management.  It* is  of  interest  to  note  that  the  overall  architectural  framework  of  PAVE 
PILLAR  is  preserved.  Intercommunications  between  Beta  functions  can  still  be  supported 
by  the  PAVE  PILLAR  high  speed  data  buses.  Intercommunications  within  meta  functions  are 
envisioned  to  be  a  hierarchial  mixture  of  high  speed  data  buses  connecting  tightly 
coupled  parallel  networks. 

PAVE  PACE 

The  PAVE  PACE  initiative  has  been  established  to  validate  the  concepts  described 
above.  This  advanced  development  initiative  is  envisioned  as  the  means  to  select  the 
appropriate  technologies,  mature  them  as  necessary  and  conduct  a  series  of  integrated 
test  bed  (ITB)  demonstrations  that  show  how  avionics  a va 1 3 abi 1 i ty ,  performance  and  cost 
can  be  significantly  improved.  Further,  the  applicability  of  the  resulting  hardware, 
software  and  tools  for  the  modernization  of  the  force  structure  and  new  aircraft  systems 
would  be  projected.  New  avionic  modules  will  be  built  and  validated  for  reliability 
enhancement.  A  modular  building  block  family  approach  to  hardware  and  software  for 
airborne  parallel  processing  would  be  demonstrated.  Advanced  CAD/CAM  tools  would  be 
exploi ted /developed  and  used  to  demonstrate  improvements  in  hardware  and  software 
design,  development  and  support.  Advanced  algorithms  would  be  developed  and  used  in  a 
real-time  ITB  configuration  using  an  advanced  crew  station  in  order  to  demonstrate 
improvements  in  situation  awareness,  fault  tolerance  and  maintenance  strategies. 

Advanced  technologies  such  as  neural  networks  would  be  investigated  in  an  integrated 
system  context . 

CONCLUSIONS 


The  Air  Force  has  faced  and  will  continue  to  tace  an  industrial  ,  political,  and 
military  environment  which  will  result  In  important  constraints  that  drive  avionics 
architectures/systems. 

High  development,  acquisition,  and  support  costs. 

Long  development  times;  7-9  years  typical. 

Post  deployment  reliability  and  maintenance. 

-  A  history  of  change  over  the  life  cycle  of  an  airplane. 
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A  limited  budget — continued  pressure  to  reduce  the  budget. 

A  developing  critical  shortage  in  technical  people-engineers,  maintenance 
technicians,  computer  programmers. 

-  "Computational  plenty"  from  generally  more  powerful  and  available  microcomputers 
which  threatens  to  swamp  the  Air  Force  with  software. 

-  An  increasingly  more  capable  and  technically  sophisticated  enemy. 

The  technical  implications  arising  from  these  constraints  shape  the  design 
decisions  and  investment  strategies  for  technology  development. 

A  history  of  avionics  change  over  the  life  cycle  of  an  airplane  due  to 
technological  pressures  and/or  operational  requirements  pressures  demand  that  avionics 
architectures  be  flexible.  Flexibility  may  imply  the  heavy  use  of  modularity  concepts 
and  clearly  defined  system  interfaces  that  allow  system  upgrade  without  massive 
perturbation  of  the  logistics  system. 

_  High  costs,  budget  constraints  and  limited  personnel  availability  dictate 
concepts  like  reusable  hardware  and  software — avoiding  the  costs  associated  with 
"reinventing  the  wheel"  syndrome.  If  an  avionics  architecture  can  support  the  use  of 
previously  developed  satisfactory  components  like  standard  subsystems  or  standard 
software  modules,  item  development  time  can  be  reduced  by  minimizing  the  number  of 
completely  new  components  and  integrating  those  with  the  standards. 

-  The  continued  influx  of  digital  systems  into  the  Air  Force  inventory,  compounded 
by  the  microprocessor  explosion  and  the  developing  critical  shortage  of  qualified 
software  people,  dictate  the  need  for  focus  on  standardized  software  support  concepts  to 
minimize  the  capital  investment  required  at  our  Air  Logistics  Centers  as  well  as 
minimizing  the  training  needed  to  qualify  support  people  on  new  software  programs. 

-  None  of  us  are  satisfied  with  the  performance,  cost,  or  reliability  of  the  bulk 
of  our  current  avionics.  The  ultimate  has  certainly  not  been  reached.  The  required 
improvements  will  principally  come  from  technology;  therefore,  a  standardization 
approach  in  avionics  architecture  must  not  stifle  this  needed  technological  evolution, 
but  should  proviae  a  framework  of  standardized  interfaces  which  can  support  insertion  of 
new  technology,  again  without  necessitpt ing  a  massive  change  in  system  support. 
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This  paper  describes  an  approach  to  avionic  system  design  and  its  application  to 
modular  avionic  architectures. 

The  approach  is  to  test  various  candidate  architectures  using  a  common  functional 
requirement.  The  method  commences  with  a  requirement  analysis  carried  out  in  a  top- 
down  fashion  to  arrive  at  a  full  functional  description.  A  parallel  phase  is  to 
determine  the  technological  base  and  define  a  number  of  candidate  architectures  and 
corresponding  component  sets  (module  sets  in  the  case  of  modular  architectures) .  Thus 
technologies  1  performance  and  in-place  equipment  limitations  are  included  at  an  early 
stage  independent  of  the  requirement.  Hence  "top-down  meets  bottom-up",  by  taking 
various  architecture  candidates  and  corresponding  modular  sets  and  applying  the 
functional  description  of  the  requirement,  so  each  architecture  may  be  investigated  for 
its  capability  to  cope  with  the  trial  or  application  system.  Assessment  of  reliability 
and  performance  objectives  is  discussed.  Also  included  is  reference  to  the  areas  of 
operating  system  and  BITE  which  may  form  part  of  the  system  but  are  not  necessarily 
directly  represented  at  the  boundaries  of  the  system. 

The  paper  deals  with  philosophy  of  the  approach  and  does  not  extend  to  application 
of  the  various  CASE  design  tools  which  exist  (or  may  be  specified)  in  order  to  carry 
out  such  a  project  in  practice. 


I  .  Background 

Firstly  I  shall  start  with  a  little  background.  Our  industries  have,  for  a  number 
of  years  now,  successfully  delivered  equipment  to  customer  requirements  which  include 
reliability  and  maintainability  considerations,  in  addition  to  performance 
requirements.  Also  we  have  operated  schemes,  such  as  reliability  improvement  warranty, 
which  have  been  aimed  at  reducing  lifecycle  costs.  Other  customers  have  operated  under 
conditions  where  their  prime  interest  has  been  to  minimise  start-up  and  initial 
purchase  costs  for  given  performance.  However,  things  are  changing,  customers  now,  at 
last,  understand  that  R  &  M  factors  can  be  built  into  equipments  from  the  beginning 
along  with  performance  requirements. 

So  by  adopting  the  advances  promised  by  new  technology  and  by  planning 
sufficiently  ahead,  new  systems  architectures  are  being  devised  which  will  enable 
minimisation  of  lifecycle  cost.  In  order  to  contain  the  potentially  increased  start-up 
costs  of  such  systems,  these  architectures  are  aimed  at  serving  more  than  one 
application . 

Because  the  lifecycle  cost  implications  of  design  are  often  not  obvious  and 
because  this  design  task  is  additional  and  very  much  complicates  the  normal  activities 
that  are  required  for  design  for  performance,  we  need  a  system  design  methodology  which 
will  enable  us  to  sort  through  the  plethora  of  technology  and  architectural  choice  in 
an  ordered  way  to  present  us  with  a  single,  or  at  least  a  reduced,  set  of  options  with 
which  to  go  forward  into  the  detailed  design  or  development  phase  for  the  system. 

Key  factors  affecting  the  new  modular  approach  to  avionics  design  are: 

.  connector  reliability 

.  maximum  power  per  module 

.  distribution  of  power  between  processing  and  I/O  on  a  module 

.  number  of  module  types 

.  policies  for  safety,  security,  mission  reliability,  maintenance, 
operation  without  maintenance,  survivability 


> 


reconfiguration  boundaries 


.  bus  connectivity/bandwidth 
.  number  of  bus  physical  layer  types 
.  level  of  BIT  performance 
.  growth  potential 

2.  Introduction  to  a  System  Design  Method 

This  paper  describes  an  approach  to  avionic  system  design  and  its  application  to 
modular  avionic  architectures.  The  study  methodology  goes  through  the  phases  of 
analysis,  synthesis  and  assessment  in  a  structured  way. 

2 . 1  Requirements  for  System  Design  Methodology 

Because  future  goals  have  now  moved  to  include  reduction  of  lifecycle  cost  and 
architectures  applicable  to  many  requirements  and  vehicle  types,  one  thing  is  certain, 
start-up  development  costs  of  such  architectures  will  not  be  low.  Also  gearings  of 
design  parameters  into  LCC  are  more  difficult  to  determine  which  makes  potential  design 
or  architecture  evaluation  much  more  complex  and  certainly  less  obvious  than  design 
requirements  driven  mainly  by  performance.  Therefore  it  is  essential  that  system 
design  methods  used  to  determine  such  systems  yield,  for  the  limitations  and  goals 
given,  the  near  optimum  solution  rather  than  solution.  Such  a  method  must  be  able  to 
show  a  visible,  traceable  derivation  of  the  solution  showing  fully  all  arguments  and 
assumptions  made  in  reducing  the  many  infinities  available  down  to  the  chosen  solution. 

The  system  design  method  must  be  manageable,  that  is  it  should  follow  a  clearly 
defined  structure,  able  to  be  broken  down  into  separate  well-defined  elements  to  enable 
experts  to  be  brought  into  the  programme  appropriately  and  to  enable  mapping  onto  a 
project  management  aid.  It  is,  for  example,  essential  that  areas  of  unexpected 
difficulty  or  need  for  additional  resource  be  shown  up  quickly  as  this  field  is  an  area 
of  potentially  high  risk,  in  that  it  combines  the  prediction  of  future  technology  with 
new  or  novel  architectural  concepts. 

The  system  design  method  must  be  able  to  combine  available  technology  performances 
to  form  candidate  architectures  for  evaluation.  Even  though  the  selected  modular 
architecture  may  be  intended  for  a  range  of  applications  it  is  important  that  it  be 
tried  on  a  real,  detailed,  requirement  in  order  that  it  be  thoroughly  tested  and  siz'd. 

In  pursuit  then  of  the  architecture,  rather  than  a  solution  as  it  would  seem  from 
the  viewpoint  of  a  particular  designer,  it  is  essential  to  separate  the  requirement  and 
requirement  analysis  from  the  technology  study.  By  the  technology  study  I  mean  the 
prediction  of  available  and  necessary  technology  for  the  period  to  be  considered. 

What  this  means  is  that  top-down  design  is  not  enough  in  itself.  A  major  feature 
for  this  method  is  that  "top-down  meets  bottom-up"  -  both  are  essential  aspects  in  the 
reduction  of  the  solution. 

As  you  are  aware  top-down  refers  to  the  structured  analysis  of  the  requi rement ( s ) 
broken  down  hierarchically  into  greater  detail  the  further  the  process  is  continued. 

Dottom-up  traditional ly  refers  to  the  use  of  in-place  equipment  or  technology  - 
clearly  an  important  part  of  the  design  method  is  the  analysis  of  what  rechnoloay  will 
be  or  could  be  made  available  in  time  for  inclusion  in  the  design. 

It  is  vital  therefore  that  a  modern  system  design  method  provides  for  both  of 
these  areas  of  influence  upon  the  overall  design  result. 

2 . 2  Method  Structure 


Fig.  1  shows  the  overa 1 1  structure  of  the  study  and  the  main  activities.  The 
activities  proceed  chronologically  top  to  bottom  of  the  diagram. 

2.2.1  Initial  Phase 


The  method  starts  with  an  Initial  Phase  in  which  the  project  is  sot-up,  the 
limitations  and  goals  are  set  or  confirmed  with  the  customer  and  one  or  more 
applications  or  missions  are  defined  at  a  user  level.  Also  this  phase  includes  certain 
vital  support  activities  such  as  literature  searches  and  determination  of  metrics  to  be 
used  during  the  study/design  period.  However  the  prime  activity  during  the  initial 
phase  is  the  mission(s)  analysis.  A  timeline  analysis  showing  the  main  functioning  of 
the  intended  system  by  phase  of  mission(s)  is  the  minimum  necessary  to  ensure  support 
of  the  follow-on  design  method  and  to  maintain  traceability  back  to  the  originating 
requirement  statement ( s )  .  The  time  line  analysis  leads  directly  into  definition  of  the 
top  level  functional  representation  of  the  system. 
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2.2.2  Requirements  Analysis 

More  detailed  analysis  of  the  requirement  may  now  be  undertaken.  This  is  based  on 
functional  decomposition  of  the  top  level  requirement.  Why  Functional?  The  reason  is 
that  the  system  design  does  not  exist  at  this  time  and  complex  modern  systems  are  high 
on  functionality  but  low  on  in-place  objects.  The  output  of  the  requirement  analysis 
is  a  set  of  functional  primitives  at  the  base  of  the  hierarchy  forming  the  functional 
decomposition . 

2.2.3  Technology  Study 

The  Technology  Study  is  aimed  at  determining  what  technology  will  be  available  to 
fit  the  required  development,  IOC,  and  lifetime  of  the  projected  system.  This  phase  of 
the  design  method  is  less  closely  coupled  to  the  mission  requirement  than  the  Initial 
and  Requirement  Analyses  Phases  and  so  may  be  run  in  parallel  with  these  two.  The 
objective  of  this  phase,  as  applied  to  modular  avionics,  is  to  arrive  at  a  number  of 
candidate  architectures  and  associated  module  sets  for  evaluation  in  the  following 
phases  . 

It  is  necessary  here  to  emphasise  the  clear  distinction  between  the  Technology 
Study  and  the  Requirement ( s )  analysis  phases  of  the  programme.  Technology  is  about 
actual  achievement  of  component  performances  and  integrated  performance  able  to  be 
achieved  in  the  timescale.  The  functional  analysis  is  totally  without  reference  to 
need  for  hardware,  except  where  it  is  'given'  at  the  boundaries  of  our  projected 
system.  So  the  difference  is  that  the  technology  phase  is  about  determination  of 
maximum  achievable  performances  whereas  the  requirement  analysis  phase  is  about 
determination  of  minimum  required  performance. 

2.2.4  Synthesis 


The  Synthesis  phase  is  to  take  the  candidate  architectures  output  from  the 
technology  phase,  and  in  turn  subject  them,  or  load  them,  with  the  requirement  as 
expressed  in  the  function  primitives  listed  from  the  requirements  phase.  Thus  each 
candidate  is  'loaded'  with  the  set  of  functional  primitives  so  sizing  the  architecture 
for  the  particular  application (s) .  It  is  only  when  this  phase  is  complete  with 
competing  designs  defined  and  sized  that  the  final  major  phase,  that  of  parametric 
studies,  may  be  commenced. 

2.2.5  Parametric  Studies 


Parametric  studies  is  the  area  in  which  quantified  assessment  of  the  remaining 
candidate ( s) ,  or  hopefully  the  selected  candidate,  takes  place.  A  division  of  the 
parametric  studies  is  shown.  The  area  of  Lifecycle  Cost  Factors  includes  other  cost 
related  components.  The  assessment  of  Performance  is  a  cross-check  to  see  that  the 
required  performance  is  achieved  and  that  performance  margins  are  identified.  Finally 
'ilities,  this  is  a  term  which  we  use  for  availability,  reliability,  maintainability, 
etc.  These  all  have  a  gearing  into  the  paramount  LCC  but  objectives  set  at  the 
beginning  of  the  project  may  include  certain  intermediate  goals  and  assessments  rather 
than  call  for  LCC  reduction  alone. 

2.2.6  Reviews  and  Conclusions 


The  final  phase  provides  for  review  of  the  results  thus  far  and  gives  an 
opportunity  to  go  back  over  the  decisions  that  have  been  made  and  revise  or  determine 
points  which  may  have  been  left  undetermined.  For  example,  only  at  this  stage  will 
loadings  and  margins  be  known,  and  if  a  finally  checked  figure  occurs  near  a  technology 
threshold,  then  implementation  will  be  reviewed.  In  addition  to  defining  the 
architecture  based  on  the  supplied  data  recommendations  may  identify  development  areas 
required  to  achieve  enabling  technology  items.  Thus  the  project  will  yield  a  means  of 
focussing  future  development  and  support  of  future  applications. 

So  that  is  an  outline  of  a  system  design  method  which  accommodates  design  of 
systems  to  objectives  which  may  contain  opposing  elements.  A  range  of  solutions  is 
generated  against  which  deterministic  evaluation  of  each  candidate  is  applied  to  one  or 
more  well-defined  requirements.  This  enables  evaluation  leading  to  selection  of  a 
particular  candidate,  or  more  realistically,  a  variation  of  that  candidate  as  the 
recommended  solution. 

I  will  now  take  each  phase  in  turn  and  explain  the  objectives  and  means  of 
achievement  of  each  phase  along  with  the  sort  of  difficulties  which  may  be  encountered 
in  practice . 
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3.  Initial  Phase 


As  the  basis  of  the  study  method  is  to  attain  traceability  from  the  required 
missions  and  other  available  input  data  through  to  the  final  design,  it  is  essential 
that  the  study  commence  with  an  overall  view  of  the  objectives  of  the  study  and 
analysis  of  the  input  material,  this  will  include  a  literature  survey. 

The  literature  survey  will  be  required  to  cover  aspects  of  the  threat  scenario  and 
projections  of  both  friend  and  foe  system  design  and  capabilities  for  the  projected  IOC 
dates  for  the  required  system.  It  will  also  require  to  research  into  the  available, 
and  able  to  be  made  available,  technologies  from  which  the  system  may  be  constructed. 
This  technical  aspect  of  the  survey  will  range  from  projected  silicon  technology 
through  to  data  transmission  media  and  data  bus  techniques.  A  key  element  in  research 
for  the  modular  avionics  is  the  performance  achievable  from  these  technologies  and  the 
ability  to  suitably  combine  them  to  provide  candidate  solutions  for  system  applications 
envisaged  during  the  lifetime  of  the  required  architecture. 

The  practical  problems  of  the  literature  survey  are  that  having  generated  a  large 
and  wide  range  bibl iography ,  the  difficulty  remains  in  imparting  the  information 
contained  to  the  members  of  the  project  team.  It  is  therefore  of  great  assistance  for 
a  literature  survey  summary  to  be  prepared,  giving  a  brief  summary  and  findings  cf  each 
item.  This  enables  team  members  to  quickly  arrive  at  a  common  starting  point  and  to 
pick  out  those  items  of  literature  which  have  particular  relevance  to  their  role  in  the 
design  activity-  The  literature  survey  needs  to  include  reference  to  future  and 
projected  relevant  standards. 

Time  Line  Analysis 

The  time  line  analysis  to  be  used  for  a  modular  avionics  design  point  will  need  to 
include  all  aspects  of  the  avionic  system  use  and  will,  therefore,  include  clear 
description  of  all  ground  environment  activities  in  addition  to  the  airborne 
performance  related  time  lines-  Omission  of  these  could  result  in  a  design  of 
seriously  limited  scope-  The  purpose  of  the  time  line  analysis  is  t)  relate  required 
mission  functions  to  phases  of  flight,  events,  and  overa 1 1  objectives,  thus  this 
analysis  will  include  necessary  attributes  of  maintenance,  replenishment  and  mission 
preparation  and  other  operational  information  necessary  to  visualise  the  full  lifecycle 
of  the  avionics  system.  Finally  the  output  of  the  initial  phase  will  provide  a  top 
level  functional  description  of  the  system  and  a  clear  statement  of  the  objectives. 

4.  Requirement (s )  Analysis 

The  last  part  of  the  initial  phase  was  to  define  the  top  level  functional 
representation  of  the  system.  There  are  many  ways  that  the  functional  representation 
of,  say,  an  aircraft  or  weapon  system  may  be  represented  at  the  high  level,  however,  we 
have  found  the  following  guide  lines  both  useful  and  practical  from  the  viewpoint  of 
those  carrying  on  the  functional  decomposition  to  lower  levels.  The  first  requirement 
is  to  ensure  that  the  functional  diagram  is  able  to  be  interpreted  back  to  the  time 
line  analysis  output  from  the  initial  study  phase.  Also  at  the  next  level  down,  it 
would  be  convenient  if  the  functional  breakdown  were  to  be  along  lines  of  areas  of 
expertise  available  to  the  study  team  in  order  that  experts  be  available  for 
consultation  as  level  of  detail  is  increased  as  the  decomposition  progresses. 

This  may  be  seen  as  upsetting  the  parity  of  the  approach  but  such  is  the  mobility 
of  placement  of  function  in  such  architectures  that  in  retrospect,  the  outcome  is  not 
affected . 

Functional  decomposition  is  the  functional  representation  method  which  is 
suggested  as  the  means  of  providing  a  hierarchical  diagrammatic  representation  of  the 
system  function  and  operation.  The  diagrammatic  method  should  be  of  a  nested  nature  as 
indicated.  This  means  that  a  block  at  a  given  level  in  the  structure  will  appear 
expanded  as  a  complete  functional  diagram  at  the  next  level  down  and  aO  on.  At  every 
stage  the  individual  diagrams  should  be  kept  as  simple  as  possible.  Blocks  in  each 
diagram  refer  to  functionality,  the  normal  rectangular  block  referring  normally  t_  a 
system  function,  the  I  >  blocks  referring  to  crew  action  and  the  f  J  blocks 

referring  to  system  display  function.  References,  annotations,  lists  and  supporting 
Lext  include  supporting  data  or  message  dictionaries  and  control  tables.  In  this  way 
system  funct iona 1 i ty  nay  be  represented  by  a  connected  set  of  system  functions,  system 
display  functions  and  resultant  crew  actions.  Representations  of  system  operation 
therefore  includes  the  crew's  activity  as  part  of  the  system. 

The  degree  to  which  functional  breakdown  should  proceed,  i-e-  the  number  of  levels 
of  functional  decomposition,  is  dependent  on  the  complexity  of  the  system,  but  should 
extend  to  the  condition  where  no  elementary  (lowest  level)  function  would  be  expected 
to  straddle  a  hardware  boundary,  i.e.  every  function  should  be  containable  totally 
within  a  single  hardware  unit.  The  lowest  functional  element  resulting  from  the 
decomposition  process  takes  the  form  of  an  elementary  functional  description  or 
"functional  primitive"  and  is  represented  in  a  standard  format  specification.  Due  to 
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the  proliferation  of  blocks  even  after  relatively  few  levels  of  functional 
decomposition,  it  is  to  be  expected  that  the  number  of  functional  primitive 
specifications  will  be  quite  large.  I  have  already  referred  to  the  disruptive  effect 
of  "loose  ends".  One  advantage  of  functional  decomposition  is  the  early  exposure  of 
such  potential  errors. 

As  the  top  levels  of  functional  decomposition  are  completed  design  reviews, 
including  customer  "walk  through",  may  be  carried  out  in  order  to  verify  the  system  in 
all  its  modes  so  that  customer  satisfaction  be  sought  at  an  early  stage. 

Clearly  the  sheer  volume  of  documentation  and  the  need  for  consistency  and  other 
checks  as  the  requirement  is  decomposed  make  this  an  area  ideally  aided  by  a  computer 
driven  system  design  tool  or  via  integration  of  a  number  of  such  tools. 

The  extent  of  the  detail  of  the  decomposition  of  the  requirement  will  be  varied 
according  to  the  form  of  the  project  being  undertaken.  Feasibility  or  an  investigative 
study  would  require  decomposi tion  to  three  or  four  levels  with  reasonable  accounts  of 
the  functions  and  the  data  flows  between  them.  The  detail  required  for  a  full  project 
would  need  to  be  more  rigorous  and  precise  in  its  definitions  but  would  not  in  fact 
need  to  be  taken  far  beyond  that  of  the  feasibility  study  in  terms  of  the  level  of 
detail  examined,  this  is  because  the  decomposition  in  both  instances  would  be  required 
to  be  taken  to  a  level  of  assumed  Functional  Primitives.  Remember  that  a  functional 
primitive  is  a  function  which,  given  the  level  of  technology  anticipated  could  be 
contained  in  a  module,  either  as  hardware,  as  software,  or  as  a  mixture  of  both,  but 
which  does  not  span  more  than  one  of  the  intended  system  units  or  modules.  More  than 
one  functional  primitive  may  be  contained  within  a  module.  Now  at  this  point  I  need  to 
reiterate  that  the  requirements  analysis  is  investigating  the  minimum  necessary 
requirements  for  the  system  to  perform  the  missions  or  system  requirement.  Because  the 
functional  primitives  are  to  be  packed  into  the,  as  yet  candidate,  module  we  need  to 
express  their  attributes  in  terms  common  to  those  used  in  the  technology  study  to 
describe  the  capabilities  of  the  module.  For  example,  a  functional  algorithm  may  be 
expressed  by  the  number  of  lines  of  Ada  code  or  the  number  of  operations  of  a 
particular  micro-processor  order  code.  A  statement  of  the  iteration  rate  of  the 
algorithm  will  also  be  required.  This  permits  the  required  number  of  MIPS  (Million 
Instructions  Per  Second)  to  be  estimated.  Other  maximum  and  minimum  requirements  will 
also  be  laid  down  in  order  to  specify  the  minimum  performance  required  in  order  that 
the  functional  primitive  meets  the  system  need.  These  include  latency,  data  storage, 
task  state  data  (in  support  of  reconfiguration)  and  estimates  of  the  total  number  of 
lines  of  code  required.  State  data  may  significantly  contribute  to  data  flows  within  a 
reconfiguration  boundary. 

Sources  and  sinks  for  input  and  output  to  the  function  along  with  estimated 
data/message  bit  rates  are  vital  in  the  following  evaluations  of  the  candidate 
architectures . 

For  a  large  system  it  will  be  appreciated  that  the  number  of  functional  primitives 
received  as  a  result  of  the  expert  teams  endeavours  will  be  large  and  time  will  be 
required  in  order  to  normalise  these  returns  as  deviations  from  the  laid  down  rules 
always  appear  to  be  made  by  experts  for  their  own  good  reasons.  Thus  in  summary,  we 
now  have  a  pile  of  functional  primitives  which  express  the  required  characteristics 
needed  to  achieve  our  system  function.  These  functional  primitives  address  both  the 
contained  functions  and  estimates  of  the  required  10  data  and  control  flows  between 
functions.  It  should  be  emphasised  that  although  there  is  some  degree  of  design 
involved  by  the  way  in  which  the  approach  to  the  functional  decomposition  is  made,  as 
yet  no  prime  design  work  has  been  carried  out  in  terms  of  architecture  selection  or 
implementation  decisions.  By  way  of  illustration,  one  could  group  the  functional 
primitives  such  that  all  the  high  computational  functions  which  contained  a  high  level 
of  computat ion  were  grouped  within  a  single  unit.  This  would  represent  a  centralised 
computer  solution.  Alternatively  functions  could  be  grouped  so  that  the  computational 
functions  were  grouped  with  their  prime  sensors,  this  would  represent  a  federated  and 
sensor-based  solution.  Thus  the  prime  importance  of  functional  decomposition  to  our 
system  design  methodology  is  that  we  are  able  to  break  down  and  assess  the 
functionality  required,  largely  independent  of  any  particular  design  implementation. 

Thus  the  functional  primitives  are  now  ready  to  be  distributed  into  the  candidate 
architectures  emerging  from  the  technical  study  according  to  the  rules  and  structures 
defined  to  characterise  each  candidate. 

5.  Technical  Study 

There  have  been  a  number  of  programmes  carried  out  which  address  the  question  of 
advanced  avionic  systems  for  the  future  and  which  have  tackled  the  reduction  in 
lifecycle  cost  along  with  achievement  of  high  performance  by  exploring  the  application 
of  combinations  of  common  modules,  advanced  data  transmission  media  and  protocols, 
integration  of  high  levels  of  BIT,  fault  tolerance  and  reconfigurability.  Therefore, 
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for  this  modular  application  of  this  study  method  key  areas  of  technology  were 
identified  which  include  topology,  electronic  technology  for  modules  and  operating 
system. 

The  purpose  of  studying  these  key  areas  is  to,  firstly,  identify  the  range  of 
technologies  available,  and  then  to  combine  these  to  provide  a  range  of  candidate 
architectures  intended  to  span  the  range  of  solutions  but  without  encumbering  the 
designers  at  this  stage  with  any  more  than  an  outline  of  the  functionality  of  the 
target  system  except  as  required  to  perceive  the  level  of  complexity  which  may  be 
entailed.  Thus  the  candidate  architectures  are  created  without  reference  to  the 
detailed  requirement  analysis  part  of  this  methodology. 

As  stated  before  the  objective  of  the  technology  study  is  to  produce  a  number  of 
candidate  architectures  along  with  associated  module  sets.  This  entails  the  projection 
of  technology  in  terms  and  different  stages  of  availability  over  the  years  leading  to 
the  required  in  service  date  i.e.  development  availability  of  components,  availability 
of  standards,  availability  for  production.  The  creation  of  logically  distinct 
candidates  is  therefore  an  important  output  from  this  part  of  the  method. 

I  should  point  out  that  it  is  just  as  important  to  close-down  options  as  good 
traceable  reasons  arise,  one  problem  that  will  be  encountered  is  that  people  will 
continue  with  a  'dead'  candidate  as  there  are  generally  always  some  good  aspects  to  a 
line  of  approach  even  though  there  exist  compelling  reasons  to  kill  it  off. 

Thus  the  main  areas  of  the  technology  study  are: 

Topology 

This  part  of  the  study  is  intended  to  reveal  suitable  topologies  for  the  future 
avionics  architecture.  It  will  therefore  need  to  take  into  account  the  various 
available  electrical  and  opto  technologies  and  bus  standards.  The  factors  which  will 
need  to  be  taken  into  account  in  deriving  these  candidate  topologies  include 
connectivity  bandwidth  v  power  and  receiver  technology,  effects  of  failure  for  ring, 
star  and  other  bus  configurations.  The  increase  in  mission  availability  may  be 
achieved  in  part  by  increasing  the  time  between  maintenance  actions  and  providing  the 
system  with  fault  tolerant  characteristics  so  that  the  system  will  remain  operational 
in  the  presence  of  fault  conditions.  The  topology  study  will  also  tackle  LCC 
contributions  directly  by  improvements  in  reliability  both  in  the  data  transmission 
system  and  again  in  its  means  of  tolerating  fault  conditions  when  they  arise.  Thus 
minimisation  of  pin  counts  and  reduction  of  juction  temperatures  within  the  data 
transmission  media  are  considerations  made  during  this  stage.  The  output  of  the 
topology  study  is  to  provide  topologies  options  from  which  the  candidate  architectures 
may  be  drawn  having  regard  to  the  parallel  outputs  from  the  electronic  technology  and 
operating  system  investigations. 

The  important  point  here  is  to  get  some  numbers  down  describing  basic  data 
transmission  building  blocks  so  that  these  may  be  built  into  systems.  At  this  stage  it 
is  all  about  bandwidth,  connectivity  and  power  budgets,  protocols  and  other  nice  points 
come  later. 

Electronic  Technology 

The  prediction  of  relevant  electronic  technology  for  the  period  for  a  future 
system  is  clearly  an  enormous  subject.  This  further  bottom  up  aspect  of  the  study 
approach  is  to  provide  a  view  of  what  could  be  available  in  terms  of  module  performance 
under  the  primary  constraints  of  size,  weight  and  power  consumption.  A  key  issue  is 
the  amount  of  silicon  that  can  be  affixed  to  a  given  size  of  module  and  the 
functionality  that  can  increasingly  be  compressed  into  a  given  area  of  silicon.  The 
primary  considerations  in  the  module  in  determining  the  future  performance  is  the 
realisation  of  certain  trade-offs,  for  example  the  power  bandwidth  trade-off  was 
identified  such  that  for  a  given  constant  power  within  an  avionics  common  module  so 
processing  power  could  be  traded-off  against  JO  bandwidth ,  thus  over  much  allocation  of 
power  to  a  CPU  will  limit  module  IO  capability  and  alternatively  overly  much  power 
assigned  to  communication  would  limit  the  effectiveness  of  the  CPU  contained  on  the 
module.  Another  trade-off  area  is  that  of  power  dissipation  within  the  module  versus 
module  reliability.  Here  cooling  arrangements  for  the  avionic  modules  limit  the  power 
dissipation  of  the  module  for  given  junction  temperatures.  Thus  given  the  critical 
relationship  between  device  reliability  and  junction  temperature,  so  rel iabi 1 ity/power 
consumption  options  are  provided  against  the  variously  available  cooling  arrangements, 
some  of  which  suit  avionic  applications,  others  because  of  their  complication  and 
maintenance  disadvantages  detract  from  lifecycle  cost  that  the  apparently  improved 
cooling  arrangment  had  promised.  Another  area  of  investigation  is  to  determine  module 
capabilities  such  that  the  total  number  of  module  types  may  be  limited.  For  example  a 
threshold  technology  which  only  permits  a  processor  to  be  carried  on  a  module  would 
entail  support  modules  of  storage  and  I/O  as  necessary  members  of  the  module  set.  With 
higher  IC  technology  so  more  self-contained  functions  may  be  conceived  so  limiting  the 
module  types  required. 
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Operating  System 

Software  cost  is  another  area  where  opportunity  for  LCC  reduction  is  potentially 
very  large.  It  has  long  been  my  contention  that  so-called  software  problems  are  more 
often  than  not,  not  the  fault  of  the  software  programmer  but  are  in  fact  rooted  in  poor 
system  design  and  in  poor  system  requirement  specifications.  Programmers  have  been 
expected  to  pick-up  these  "loose  ends"  i.e.  an  undetermined  condition  for  which  no 
outcome  is  defined,  and  knit  them  into  the  system.  It  is  only  when  the  operator  comes 
upon  this,  possibly  obscure,  event  that  the  system  specification  fault  is  revealed.  At 
the  other  end  of  the  programmers'  task  we  see  that  they  have  been  called  upon  to  "hook" 
their  programs  into  the  hardware  interface  further  adding  to  the  compl ications  of  their 
immediate  task.  This  may  explain  the  apparent  obsession  these  days  with  object 
orientated  design  techniques  rather  than  with  functional  design  techniques. 

Thus,  in  conjunction  with  the  use  of  modern  CASE  tools  for  system  detailed  design 
and  configuration  control,  the  long  overdue  avionics  operating  system  is  considered  a 
necessary  adjunct  for  modular  avionics. 

The  operating  system  is  required  to  provide  a  common  transparent  interface  between 
the  application  software  and  the  avionics  system.  Where  a  candidate  architecture  is 
reconf igurable  so  this  would  be  supported  by  the  operating  system. 

The  transparency  I  talk  of  enables  a  software  task  programmer  to  communicate  with 
other  tasks  by  reference  to  the  other  task  name  and  name  of  the  data  only,  i.e.  message 
passing  without  reference  to  the  location  of  the  other  task  within  the  system.  This 
permits  large  systems  to  be  composed  of  separately  compiled  code  and,  of  course,  aids 
the  support  of  reconfigurable,  load  balancing  system  candidates.  To  software  the 
importance  of  reconfiguration  is  not  so  much  after  a  failure,  but  at  start-up  with  a 
new  application  task  aboard,  it  will  be  accepted  with  whatever  priority  it  has  been 
assigned,  just  as  if  it  had  always  belonged  to  the  club. 

Candidate  Architectures 

Candidate  architectures  are  derived  as  the  output  of  this  bottom  up  technology 
driven  part  of  the  study  by  covering  topology  and  electronic  technology  considerations 
to  provide  maximum  module  processing  performance  while  minimising  10  bottle-necks  while 
the  operating  system  considerations  help  shape  the  topologies  by  providing  insight  into 
the  way  in  which  fault  tolerance  and  reconfigurability  will  be  available  within  the 
system  and  hence  the  way  that  these  factors  influence  the  design  of  the  common  modules. 
An  example  here  is  that  if  a  module  set  were  to  be  designated  such  that  a  processor 
module  always  had  to  work  in  conjunction  with  a  memory  module  and  an  10  module  then 
upon  the  need  for  reconfiguration  it  can  be  seen  that  reconfiguration  would  ha  ye  to  be 
carried  out  by  reconfiguring  in  groups  of  three  such  modules  rather  than  assigning 
reconfiguration  to  just  one.  Thus  a  leaning  towards  self-contained  modules  that  are 
able  to  stand  alone  on  the  bus  structure  is  preferred.  Architectures  based  around  such 
modules  will  considerably  aid  reconfiguration  and  this  is  the  key  to  achieving  the  high 
availability  low  LCC  system. 

6.  Synthesis 

We  have  now  reached  a  stage  where  we  have  candidate  architectures  and  associated 
module  sets  defined  by  the  technical  study  and  the  functional  requirements  of  the 
system  defined  by  the  functional  decomposition  diagrams  and  the  functional  primitives. 
The  process  of  building  the  system  now  takes  place  whereby  the  design  team  will  take 
each  of  the  candidate  architectures  in  turn  and  load  the  functional  primitives  in 
accordance  with  the  approach  defined  for  each  architecture.  In  an  architecture  which 
includes  reconfiguration  these  module  quantities  will  be  based  on  an  initial,  assumed, 
configuration  and  may  not  correspond  to  the  actual  real  time  distribution.  Thus  we  can 
treat  architectures  which  use  a  "virtual  machine  approach”,  i.e.  where  an  operating 
system  assigns  tasks  to  modules  as  part  of  a  reconfiguration  basis.  So  the  total 
number  of  modules  required  for  each  candidate  can  now  be  determined.  It  is  only  when 
this  stage  is  completed  that  the  design  team  can  stand  back  and  appreciate  the  initial 
relative  merits  of  the  candidate  archi tectures  when  loaded  in  their  different  ways  with 
the  requirement ( s )  represented  by  different  distributions  of  the  functional  primitives. 
This  stage  provides  bus  capacity  for  basic  functionality,  and  reconfiguration  as  a 
result  of  failures.  To  this  will  need  to  be  added  considerations  for  growth  and 
survi vabi 1 ity . 

After  a  period  for  review  the  method  now  moves  into  the  parametric  study  phase  in 
order  that  quantitative  assessment  of  the  candidates  may  be  made. 

7.  Parametric  Studies 


With  the  completion  of  the  synthesis  task,  we  now  have  our  remaining  candidate 
systems  expressed  in  ways  and  in  enough  detail  so  that  experts  may  now  be  made 
available  in  order  to  evaluate  the  key  parameters  necessary  for  final  selection  and/or 
verification  of  the  selected  architecture.  This  is  important  as  such  experts  are  not 
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able  to  contribute  these  skills  for  a  system  expressed  only  in  high  level  terms?  they 
require  the  problem  to  be  reduced  to  technology  and  functions  of  which  they  have 
knowledge  or  expressed  in  terms  with  which  they  are  familiar  in  order  to  extrapolate 
from  their  experience/database .  Once  this  is  achieved  they  are  able  to  envisage 
hardware  and/or  software  implications  of  the  required  modules  or  candidate  system 
components .  Hence  confidence  is  added  to  the  design  data  and  the  discriminants  between 
options . 

I  hinted  in  my  introduction  to  the  method  that  suitable  division  of  the  parametric 
studies  areas  may  be  along  the  lines  of  a  lifecycle  cost  study ,  a  performance  study  and 
an  ’ ilities  study.  Whatever  the  breakdown  of  the  parameters  which  are  indeed  chosen 
and  which  will  therefore  contribute  to  selection  and  verification  of  the  selected 
architecture,  it  is  most  important  to  realise  that  these  teams  cannot  start  from  day 
one  with  the  loaded  candidate  architectures  alone.  It  is  vital  that  the  metrics  ar.d 
methods  by  which  these  parameters  are  to  be  determined  are  ascertained  in  parallel  with 
the  other  main  phases  of  the  work  in  order  that  they  are  ready  and  in-piace  for  use 
from  day  one  of  the  parametric  study  phase . 

8.  Conclusions 

We  have  used  this  methodology  applied  to  a  study  investigating  the  advances 
attainable  in  avionics  systems  around  the  turn  of  the  century,  and  included  in  this  the 
effect  of  modular  techniques.  Overall  objectives  were  a  reduction  in  LCC  while  meeting 
the  predicted  threat,  with  an  ability  to  track  the  changing  threat  incrementally.  It 
was  shown  that  such  objectives  could  be  met.  Initial  design  costs  could  be  defrayed  by 
applying  the  system  elements  across  a  wide  range  of  future  applications.  A  significant 
factor  arising  from  the  results  is  the  increase  in  availability  and  the  ability  to 
operate  for  extended  periods  without  need  for  maintenance. 

The  number  of  module  types  was  reduced  even  below  our  first  objective  figures  and 
very  significantly  we  feel  that  we  have  at  last  capped  the  ever  growing  software 
problem  by  evolving  an  approach  in  which  good  system  design  and  system  design  tools  are 
used  to  produce  clear  bounded  software  tasks  simply  interfaced  through  an  operating 
system.  This  supports  message  passing,  reconfigurability,  including  load  balancing, 
and  maintenance  to  provide  a  transparent  interface  at  system  and  vehicle  component 
level  operation.  Simplicity  of  operation  at  all  levels  has  been  achieved  while 
investigating  application  options  which  include,  AI  and  advanced  mission  management 
aids  leading  into  future  intelligent  vehicle/weapon  systems. 

It  is  a  relief  that  so  early  in  man's  development  of  systems,  that  his  ability  to 
conceive  developments  will  not  be  limited  by  his  ability  to  implement  them. 

With  a  reconf igurable  system  margins  may  be  reduced.  If  further  facilities  are 
required  then  these  may  be  added  to  the  system,  thus  avoiding  the  heavy  contingency 
margins  associated  with  LRU  solutions. 

These  advances  are  primarily  made  possible  by  the  new  architectures,  module 
MTBF’s  are  only  moderately  better,  the  technology  contribution  is  to  lift,  module 
capability  over  the  thresholds  that  make  this  possible. 

The  most  gratifying  conclusion  was  the  ability  of  the  system  to  achieve  mission 
success  over  protracted  periods  with  zero  maintenance  support. 

Thus  we  have  used  this  methodology  and  found  it  workable  and  capable  of  producing 
the  results  by  ensuring  that  contributors  make  the  correct  consideration  and 
contributions  in  time  and  at  the  right  point  in  the  study,  enabling  diverse  and 
opposing  elements  to  be  weighed  and  worthwhile  conclusions  drawn. 
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Abstract 


The  use  of  a  rapid  prototyping  approach  in  the  initial  stages  of  complex  avionics  system  design  can 
complement  some  traditional  computer  design  method.  In  fact  most  of  the  computer  aids  in  engineering  and 
design  is  aimed  to  a  better,  coherent  and,  as  far  as  possible,  complete  description  of  the  project,  but 
not  too  much  is  done  on  the  verification  of  the  proposed  concept  implementation. 

This  paper  discusses  the  advantages  to  have  available  in  short  tine  during  the  early  design  a  software 
prototype  of  the  system  to  highlight  undesirable  characteristics  or  possible  improvements  when  the 
system  has  an  high  degree  of  complexity. 

Then  a  design  tool  called  ECATE  (Expert  Consultant  for  Avionics  System  Transformation  Exploitation), 
developed  by  Avionics  Systems  Group  of  Aeritalia,  is  described.  ECATE  is  an  expert  system  that 
prototypes  the  information  handling  architecture  of  an  avionics  system. 

The  use  of  knowledge  engineering  and,  in  general,  artificial  intelligence  approach  for  the  rapid 
prototyping  has  been  proven  very  effective,  because  of  the  high  flexibility,  complex  domain  mastering 
capability,  and  heuristic  methods  typical  of  these  techniques. 

Finally  a  description  of  a  complete,  integrated  environment  for  the  rapid  development  of  prototypes  of 
avionics  systems,  by  using  artificial  intelligence  and  computer  tools,  is  given. 


1 .  Introduction 

The  increasing  complexity  of  the  systems,  and  a  greater  consciousness  that  "components"  make 
"systems",  has  pushed  toward  a  larger  effort  in  enhancing  the  effectiveness  of  the  system 
engineering  science. 

System  engineering  has  been  defined  the  study  of  a  system  concept  in  order  to  define  its 
effectiveness  and  performance  and  to  document  results  in  specifications ,  from  which 
hardware/software  can  be  designed,  developed  and  verified  |1|. 

More  in  general,  the  system  engineering  can  be  considered  the  technical  methodology  that  allows  to 
develop  a  system  in  an  organized  way  with  minimum  effort  and  maximum  performance. 

Pioneers  in  the  field  were  the  avionics  engineers,  who  were  forced  to  new  and  more  effective 
approaches  to  the  design  and  development  of  the  electronic  suite  of  the  military  aircraft.  In  fact 
the  rapid  development  of  electronics  caused  an  increase  in  the  demand  of  performances,  and 
consequently  cost  and  complexity  in  a  rapidly  growing  spiral. 

This  is  specially  true  in  military  avionics  where  the  environment  is  extremely  competitive  and  the 
challenge  very  high. 

On  the  other  side  if  the  causes  are  identified  in  the  technology  and  the  competition,  the  solutions 
can  be  found  in  the  technology  and  in  the  scientific  environment  in  which  the  actors  of  the  system 
engineers  move.  In  other  words,  if  computer  and  digital  circuits  are  the  major  factor  in  the 
electronics  development,  they  can  also  be  used  to  aid  the  system  engineering;  the  results  of  the 
scientific  views  of  the  system  can  be  used  in  the  practice  of  the  system  engineering. 

However,  whilst  the  tools  are  the  most  up-to-date  (supercomputer,  CAE,  CAD  Work  Station  etc.)  there 
is  still  a  lack  of  integration  among  them  because  only  now  an  holistic  methodology  is  becoming 
popular  for  the  system  development. 

Let  us  recall  what  are  holism  and  reductionism  by  quoting  Douglas  Hofstadter  J  2  J  s 

"Crab:  HOLISM  is  the  most  natural  thing  in  the  world  to  grasp.  It  is  simply  the  belief  that  the 
whole  is  greater  than  the  sum  of  its  parts.  No  one  in  its  right  mind  could  reject  holism. 

Anteater:  REDUCTIONISM  ia  the  most  natural  thing  in  the  world  to  grasp.  It  is  simply  the  belief 
that  a  whole  can  be  understood  completely  if  you  understand  its  parts,  and  the  nature  of  their  sum. 
No  one  in  her  left  brain  could  reject  reductionism". 

To  break  the  system  in  subsystems  and  components,  each  with  the  minimum  possible  interaction  with 
the  others  ia  an  example  of  reductionism  in  the  design.  To  conduct  performance  simulations, 
specification  preparation,  installation  studies  etc.  almost  independently  is  an  example  of 
reductionism  in  development. 
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To  make  a  prototype  to  check  how  the  complete  system  works,  1b  an  holistic  approach  to  the 
development.  To  design  a  system  as  an  integrated  network  of  sensors,  displays  and  computers,  with 
the  maximum  possible  flexibility  can  be  said  holism. 

In  the  last  years  the  holistic  approach  has  been  more  widely  used  in  the  design,  thanks  to  the 
higher  performances  it  can  ensure,  specially  at  the  highest  complexity  levels:  the  development  is 
still  essentially  reductionism,  being  prototypes  build  only  in  the  latest  stages  of  it. 

It  is  clear  that  an  approach  in  design  and  development  only  holistic  or  reductionistic  cannot  be 
"the  answer",  but  a  correct  mix  works  effectively. 

The  factor  limiting  a  more  comprehensive  and  integrated  development  has  been,  up  to  now,  the  lack 
of  suitable  and  widely  available  tools  and  methods  to  treat  large  and  complex  systems  and  theferore 
it  was  convenient  to  break  the  system  into  smaller,  simpler  units. 

However  it  is  our  belief  that  the  Artificial  Intelligence  tools  and  methods  now  available  can 
extend  the  holistic  approach  to  the  earliest  stages  of  the  development  with  evident  benefit  in 
terras  of  result  and  performance. 

The  rapid  prototyping  is  the  way  to  consider  the  system  as  a  whole  also  during  the  concept 
definition,  feasibility  or  definition  studies  and  to  get  better  understanding,  using  also 
heuristics,  of  what  will  be  the  system  when  made. 

The  following  paragraphs,  illustrating  some  theoretical  considerations  upon  the  system  project  life 
cycle,  intend  to  explain  the  need  for  a  rapid  prototyping  methodology. 

2.  Theoretical  Considerations 


2.1 .  The  Project  Life  Cycle 

In  order  to  establish  the  need  for  a  rapid  prototyping  it  is  first  necessary  to  have  a  brief  look 
at  the  avionics  system  life  cycle.  The  project  phases  may  be  described  by  means  of  a  "waterfall" 
block  diagram,  a  graphic  representation  which  was  and  is  widely  used  for  software  projects;  it  does 
not  take  into  account  explicitely  for  feedbacks  but  it  is  clear  and  simple  and  it  will  be 
integrated  by  other  symbols  later.  For  the  purpose  of  this  paper  it  is  sufficient  to  consider  seven 
major  steps,  see  fig.  1;  on  top  of  the  figure  are  also  indicated  other  current  denomination  of  the 
project  phases. 

It  is  clear  that  each  project  can  have  its  own  names  for  the  phases,  established  according  to 
Gove rnment/Cus toner  or  internal  rules;  the  diagram  of  fig.  1  is  only  an  example  that  will  be  used 
in  this  paper  to  locate  the  rapid  prototyping  methods.  The  project' phases  of  fig.  1  establish  a 
base  for  the  understanding  of  the  project  evolution,  but  their  definition  does  not  intend  to  be 
complete  or  final;  hereafter  the  complete  life  cycle  of  the  project  will  be  named  "development", 
while  the  Design,  Build,  Integrate  and  Test  phase  will  be  called  "full  scale  development". 

The  Operational  Requirement  Analysis.  This  phase  groups  everything  before  the  actual  definition 
study  of  the  avionics  system  and  includes  many  activities  ranging  from  conceptual  studies  of  the 
weapon  system,  aerodynamics  simulations,  to  the  feasibility  study,  all  seen  from  the  avionic  point 
of  view.  All  these  activities  are  aimed  to  establish  "what  the  avionics  system  shall  do”.  The 
duration  of  this  phase  is  probably  the  most  sensitive  to  political  and  technical  considerations 
not  only  depending  upon  the  size  of  the  project,  it  can  span  from  few  months  to  several  years. 

An  important  factor  to  consider  is  that  many  activities  run  in  parallel  and  extend  also  to  the  next 
phase  in  a  continuous  refinement  of  the  requirements. 

The  System  Definition.  After  the  first  general  idea  of  the  system  functional  architecture  was  given 
in  the  previous  phase,  now  the  avionics  is  more  deeply  studied  to  precisely  define  what  are  their 
major  subsystems,  components  and  what  performance,  in  general  terms,  are  to  be  expected  by  them  and 
by  the  whole  system.  A  precise,  functional,  HW/SW  architecture  is  established,  the  functional 
performances  are  computed,  overall  installation,  electrical  interface  are  described,  general 
standards  and  procedures  prepared  and  project  design  and  management  tool  chosen. 

The  aim  of  this  phase  is  to  show  "how  the  system  looks  like  and  works". 

Also  this  phase  is  sensitive  to  other  factors  than  the  Bize  of  the  project  and  the  available 
resources,  although  this  occurs  less  frequently  than  in  the  previous  phase,  its  duration  can  range 
from  few  months  to  years. 

Design.  All  system  components  defined  in  the  previous  phase  need  to  be  bought  or  made  and  therefore 
they  shall  be  specified  or  designed  and  all  supporting  procedures  and  methods  shall  be  made 
available.  Today  it  means  to  specify  each  equipment  and,  often,  to  standardize  or  specify  some 
important  sub  components,  like  microprocessors,  connectors  etc.  and  to  choose  the  software 
development  tools.  Design  include  always  the  system  software  and  in  particular  the  mission  relevant 
software,  which  is  usually  designed  specifically  for  the  project  either  by  the  airframe 
manufacturer  or  by  the  avionic  system  responsible  company  or  under  their  direct  control,  because  it 
is  a  major,  highly  complex  component  of  the  system  and  a  key  factor  for  its  success. 

The  aim  of  this  phase  is  therefore  "to  describe  in  all  detail  the  system,  its  components  and  their 
interactions" . 


It  can  be  said  that,  roughly,  the  duration  of  this  phase  is  directly  proportional  to  the  size  of 
the  project  and  inversely  proportional  to  the  available  resources. 


Build.  All  components  specified  or  designed  in  the  design  phase  need  to  be  build.  The  difficulty  of 
this  phase  clearly  depends  not  only  by  the  size  of  the  system  but  mostly  by  other  factors,  like  the 
technological  background  of  the  suppliers  in  respect  to  the  requirements  and,  more  in  general,  it 
depends  upon  how  advanced  is  the  system,  in  absolute  and  relative  terms.  Aim  is  "to  provide  the 
components  of  the  system" .  Excluding  all  research  necessary  to  form  the  tecnology  background, 
usually  this  phase  lasts  from  one  to  three  years. 

Integration  and  test.  Each  system  component  need  to  be  verified,  to  check  if  it  complies  with  the 
specification  prepared  by  the  system  designer;  a  deviation  from  the  requirements  always  results,  in 
some  way,  in  a  system  performance  modification.  Therefore  it  shall  be  known  before  to  pass  to  the 
other  project  phases  and  to  the  second  part  of  this  phase  that  consists  of  the  integration  of  all 
components  to  build  the  whole  system,  including  the  integration  of  the  mission  software  in  the 
relevant  avionics  computers. 

Aim  of  this  phase  is  "to  verify  if  the  system  and  its  components  were  build  and  interact  as 
specified" . 

Duration  is  depending  not  only  by  complexity  and  resources  by  also  by  the  effectiveness  of  the 
tools  and  methods  used. 

Validation.  When  it  has  been  verified  that  all  component  correspond  to  their  specification  and  they 
work  together  as  predicted,  it  shall  be  demonstrated  that  they  make  the  system  that  was  conceived, 
or,  in  other  words,  the  design  shall  be  validated.  Validation  of  the  design  means  to  prove  that  its 
specification  corresponds  to  its  definition  and  the  definition  to  the  requirement.  More  than  other 
this  phase  requires  independent  interpretation  of  the  work  done  in  the  previous  phases,  in  order 
not  to  fall  in  the  same  mistakes  already  done  by  the  designers  from  definition  to  design.  Most  of 
the  previous  phases  are  carried  out  by  independent  teams,  but  it  is  a  special  need  of  the 
validation  to  be  prepared  and  performed  by  different  people  than  the  design  team. 

Aim  is  "to  check  if  the  system  looks  like  and  performs  how  intended". 

More  than  the  previous  phase  the  validation  depends  upon  the  tools  and  the  methods,  that  include 
also  flight  test;  its  duration  is  usually  some  years  and  often  if  overlaps  in  time  with  the 
integration  and  test. 

In  Service.  The  avionics  system  is  not  a  self  standing  product  but  it  is  part  of  a  weapon  system 
for  the  military  ones  and  of  a  transport  system  for  the  civil  ones.  '"Ve  in  service  phase  regards 
the  use  by  the  Customer  of  the  avionics  integrated  in  the  larger  system;  for  the  purpose  of  this 
paper  it  is  considered  up  to  the  reaching  of  the  final  operational  clearance,  when  the  Customer 
explored  in  all  najor  aspects  the  system  behaviour.  Now  it  can  be  proven  "if  the  system  operations 
corresponds  to  its  requirements". 

Again  this  is  a  very  complex  activity  that  lasts  in  many  cases  some  years  and  it  tends  to  have  a 
large  overlap  with  the  previous  one. 

It  is  worth  to  highlight  that  not  only  there  are  overlaps,  often  large,  between  the  project  phases 
described  above  but  also  there  are  forward  and  backward  loops  that  largely  influence  the  actual 
project  development  and  the  system  engineering  practice.  When  a  modification  in  a  component 
specification  occurs  niter  its  construe;  i-.n  begun  it  is  an  example  of  forward  loop;  when  a 
modification  in  a  specification  is  needed  as  result  of  an  integration  test  it  is  a  feedback. 
Clearly  forward  and  backward  loops  can  occur  between  each  phase,  for  instance  there  is  a  feedback 
wh^n  a  review  meeting  held  during  the  design  induces  some  change  in  the  system  architecture,  and 
consequently  it  effects  pr-  :  agate  down  into  the  following  stages.  However  only  some  loops  take  a 
major  role  in  the  project  because,  either  they  tend  to  be  excluded  from  the  main  path  of  the 
project  (some  operational  requirements  may  change  also  when  the  system  is  under  validation  but  this 
is  usually  treated  as  an  "addition"  to  the  original  scope  of  the  proje  t)  or  they  are  rare  or  not 
very  relevant  from  the  point  of  view  of  the  resources  required  to  fix  the  problem.  Another 
important  aspect  is  the  correspondence  between  the  various  project  phases,  that  is  the  fact  that 
certain  characteristics  are  established  in  a  phase  and  demonstrated  in  another  one  (for  instance 
the  design  and  integration/ test  phases). 

£ulh  characteristics  o*.  -i>c  iii.  cycle,  Icons  and  em  r-'^pondances,  have  important  consequences  upon 
the  effectiveness  of  the  development  methodology  and  the  tools  required;  they  will  be  illustrated 
in  the  following  paragraphs;  to  conclude  fig.  2  illustrates  graphically  the  two  characteristics 
above  said. 
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2.2.  Tools  and  Methods 


The  project  life  cycle  illustrated  in  the  previous  paragraph  is  implemented  by  means  of  the  methods 
of  the  system  engineering  supported  by  proper  tools. 

Each  phase  has  its  own  problem,  approached  by  a  proper  methodology  and  the  tool  that  implmenta  it; 

j.n  the  past  almost  all  tools  were  independent,  one  tool  and  one  method  for  one  problem,  only  in  the 

last  few  years,  come  out  some  "integrated  development  environment"  that  trays  to  integrate  many 
tools  across  some  of  the  project  phases  or  provide  a  set  of  dedicated  utilities  designed  according 
to  a  common  guideline  of  development. 

Great  impulse  toward  that  direction  was  given  by  the  software  engineering,  the  software  and 
particularly  the  mission  software  of  the  avionics  system,  has  a  life  cycle  parallel  to  that  of  the 
avionics  and  corresponding  to  it  almost  from  the  beginning.  The  rapid  growth  of  the  avionics 
software  in  terms  of  complexity,  cost  and  importance  for  the  success  of  the  development  has  pushed 
to  an  higher  use  of  automated  tools  and  methods  for  its  development. 

From  the  minimum  set  of  compiler,  assembler,  linker/loader,  necessary  to  generate  the  executable 

from  the  source  code,  the  tools,  again  all  based  on  the  use  of  digital  computers,  grew  to  an 

integrated  development  environment  that  covers  from  the  design  to  the  integration/test,  including 
configuration  control,  quality  assurance,  resource  management  etc.  Tools  such  as  the  Program 
Development  Language  (PDL)  or  the  Interactive  Symbolic  Debugger  (I SD)  gave  new  perspectives  to  the 
development  methods,  previously  based  on  experience  and  skill  only. 

The  importance  of  the  influence  of  software  engineering  upon  system  engineering,  as  far  the  new 
methodologies  are  concerned,  is  highlighted  by  the  fact  that  one  of  the  first  applications  of  rapid 
prototyping  was  the  software  requirement  preparation,  which  is  not  well  supported  by  the 
conventional  development  environments.  The  success  of  the  new  approach  to  the  software  development, 
which  complexity  can  be  sometimes  comparable  or  higher  then  an  entire  avionics,  lead  to  its  use 
also  in  the  system  development. 

This  had  the  consequence  to  boost  the  use  of  digital  computers  and  to  extend  those  methodologies  to 
the  earliest  phases  of  the  development  which  previously  were  left  mainly  to  experience  and  skill. 
The  computers  set  the  standard  for  the  Flight  Test  Instrumentation,  Ground  Stations  for  on-line  and 
off  line  data  reduction  and  elaboration,  integration  and  validation  ground  rigs,  Test  Equipment  and 
so  on.  Computer  Aided  Engineering  (CAE),  Design  (CAD),  Manufacturing  (CAM)  workstations  are 
integrated  into  the  Computer  Integrated  Manufacturing  (CIM)  facilities,  which  take  care  of  some 
important  aspects  of  the  avionics  design.  Also  important  are  the  simulation  facilities  and  the 
operational  research  tools,  specially  in  the  requirement  analysis  phase.  This  short  list  of  tools 
does  not  want  to  be  exhaustive,  but  it  is  worth  to  recall  everybody's  experience  in  this  field; 
however  for  the  purpose  of  this  paper  it  is  necessary  to  mention  the  tools  that  can  be  used  in  the 
definition  and  design. 

The  tools  known  to  the  author  are  aimed  to  the  description  of  the  system  at  the  lower  convenient 
level  by  means  of  a  formal  language  and/or  graphic  tools,  they  are  examples  of  a  methodology  that 
can  be  said  reductionistic,  in  fact  the  system  and  its  functions  shall  be  broken  into  sub-systems, 
major  assemblies,  part  and  components,  each  isolated  as  unit  and  connected  to  the  other  by  means  of 
a  clearly  defined  interface.  The  operation  to  divide  in  parts  the  system  is  guided  and  coherency 
check  can  be  automatically  performed  at  the  end  of  the  operation.  A  formal  description  of  the 
system  is  very  important  for  the  definition  and  the  design  to  minimize  the  redundancies.  It  greatly 
helps  the  designer  in  clarifying  the  requirements  and  the  corresponding  implementation, 
particularly  from  the  point  of  view  of  the  functional  characteristics.  The  formal  description  of  a 
system  previously  or  originally  described  only  by  means  of  plain  englis h  words  avoids,  in  most  of 
the  cases,  to  forget  some  required  characteristics,  to  generate  a  design  which  is  not  coherent 
with  the  requirements  or  to  forget  something  in  the  design  of  the  architecture.  The  overall  result 
can  be  summarized  saying  that  the  use  of  a  tool  that  formally  describe  the  system  reduce  the 
forward  loops  in  the  life  cycle  as  defined  in  the  previous  paragraph  and  illustrated  in  fig.  2. 
However  it  shall  be  pointed  out  that  an  important  aspect  of  the  early  phases  of  the  development  is 
not  taken  into  account  by  a  formal  descriptor. 

Certainly  it  is  not  the  scope  of  these  means  but  nothing  advices  the  designer  when  the  system  he 
defined  or  designed,  works  or  how  good  is  its  behaviour.  Moreover  their  use  shows  insufficient 
results  the  earlier  are  the  phases,  clearly  because  the  data  are  insufficient  for  a  complete 
description.  Again  those  considerations  and  results  are  left  to  the  experience  and  skill  of  the 
design  team. 
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2.3*  The  system  engineering 

Many  are  the  needs  for  an  organized  way  to  proceed  with  the  system  development:  minimization  of 
time  and  cost,  configuration  control,  quality  assurance,  producibility  and  so  on:  no  question  can 
be  raised  on  the  need  for  the  system  engineering  in  the  avionics  system  development 
However,  specially  when  the  complexity  in  high,  an  organization  is  not  enough,  but  a.1,  effort  shall 
be  made  to  minimize  the  forward  and  backward  loops  in  the  life  cycle  (para.  2.1.). 

In  fact  one  of  the  greater,  if  not  the  greatest  cause  of  increase  in  time  and  cost  of  complex 
avionics  project  can  be  found  in  the  modifications  induced  by  mistakes  or  omissions  made  in  the 
first  stages  of  the  development. 

There  are  many  examples  of  project  in  which  the  need  for  architectural  changes  or  more  computing 
power,  was  discovered  only  when  the  system  was  at  the  validation  stage,  with  dramatic  impact  on  the 
project  itself.  Even  if  that  level  is  not  reached,  it  is  clear  that  every  change  in  the  system  has 
a  cost,  in  terms  of  money,  time  and  resources,  which  increases  more  than  linearly  with  the  stage 
of  development  in  which  it  is  introduced  (see  fig.  3). 

A  typical  distribution  of  the  modification  in  a  system  developed  in  a  conventional  way  is  shown  in 
fig.  4;  the  modifications  do  not  include  those  generated  by  the  current  development  phase  but  only 
the  consequences  of  errors  made  in  all  previous  phases,  excluding  significant  Operational 
Requirements  changes.  It  is  evident  that  most  of  the  modifications  came  out  when  the  system  was 
assembled  and  tested  in  its  global  functioning;  the  corresponding  cost  in  very  high  (data  from  some 
software  development  projects,  which  can  be  considered  a  good  example  of  complex  system 
development,  show  that  the  above  described  situation  can  more  than  double  the  overall  cost). 

The  errors  cannot  be  avoided  but  they  can  be  minimized  and  their  occurrence  and  the  corresponding 
changes  shifted  to  the  left,  i.e.  toward  the  earliest  stages  of  development;  it  means  to  reduce,  as 
far  as  possible,  the  loops  in  the  life  cycle  and,  above  all,  the  feedback  loops,  which  are  the  most 
dangerous,  because  they  induces  modifications  when  the  system  is  build  and  assembled. 

The  methodology  that  requires  a  formal  description  of  the  project  down  to  the  smallest  suitable 
scale  (see  previous  paragraph)  is  a  significant  step  toward  that  objective,  because  it  greatly 
reduces  the  forward  loops  in  the  first  development  stages  and  avoids  some  of  the  changes  arising 
during  integration/test.  A  complete,  formal  and  coherent  description  of  the  system,  its 
requirements  and  its  interfaces  avoids  some  unpleasant  findings  when  the  various  components  are  put 
together  and  tested  during  the  integration  phase.  The  above  methodology  has  been  already  employed 
in  a  number  of  projects  and  preliminary  results  known  to  the  author  call  for  a  reduction  of  the 
cost  of  the  order  of  1556,  which  is  anyway  a  significant  result.  However,  assuming  that  the  system, 
when  integrated,  work  as  required  by  its  specification,  there  are  other  classes  of  problems  that 
come  out  during  the  validation. 

The  validation  of  an  avionic  system  is  a  complex  and  multistaged  activity,  it  starts  with  tests  on 
ground,  in  the  lab  and  on  the  aircraft,  and  continues  with  flight  tests.  As  said  in  para.  2.1,  its 
purpose  in  "to  check  if  the  system  looks  like  and  works  as  intended". 

In  general  terns,  there  are  two  types  of  malfunctions  made  evident  by  the  validation  activity, 
first  it  may  happen  that  the  implementation,  although  formally  correct,  does  not  correspond  to  the 
thinking  of  the  designer.  Example  could  be  a  synthetic  display  not  replicating  satisfactorily  the 
corresponding  conventional  instrument.  Secondly  the  solution  chosen  by  the  designer,  although 
correctly  implemented  and  theoretically  satisfactorly ,  is  not  adequate  when  proven.  Example  could 
be  a  data  transmission  based  on  a  hierarchy  of  several  data  bus  that  propagate  unacceptably  the 
transmission  errors.  Both  categories  of  problems  are  typical  of  an  insufficient  study  of  the 
critical  characteristics  of  the  system  architecture  considered  by  an  overall  point  of  view  and  it 
is  generated  by  the  attitude  of  the  designer  to  segment  its  design  problem  into  "vertical"  slices, 
that  is  to  consider  almost  only  the  "equipment”  aspect  rather  then  the  "architecture"  aspect  of  the 
system.  This  methodology  tends  to  allocate  the  functional  characteristics  of  a  system  to  its 
components  rather  than  consider  it  a  global  attribute. 

For  example  in  a  system  based  on  a  STANAG  3638  data  bus  the  data  transmission  function  does  not 
reside  only  in  the  bus  controller  but  also  in  the  remote  terminals  of  each  equipment  and  in  the 
host  subsystems,  a  complete  design  of  the  data  transmission  system  cannot  ignore  it. 

Of  course  the  formal  description  methodology  cannot  be  disregarded,  but  on  the  contrary,  shall  be 
pursued  in  all  its  implications,  increasing  as  necessary  the  level  of  description,  but  it  is  also 
worth  to  have  an  "horizontal"  view  of  the  system.  It  means  that  can  be  very  fruitful,  in  reducing 
most  of  the  annoying  feedbacks  of  the  validation,  to  consider  some  aspects  of  the  design  from  an 
overall  point  of  view  early  on  the  development. 

Early  prototypes  of  the  criticals  aspects  of  the  system  architecture  and  design  can  help  very  much 
In  avoiding  unwanted  side  effects  by  clarifying  the  component  interaction,  they  improve  the  design 
and  reduce  induced  costs,  and,  in  general,  carry  on  the  objective  of  the  system  engineering. 
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2.4.  The  rapid  prototyping 

Primary  scope  of  the  rapid  prototyping  methodology  is  to  provide  the  designers  with  means  to 
improve  their  understanding  of  the  system  architecture  they  are  conceiving.  As  the  nomination  says, 
the  understanding  is  gained  by  exercising  prototypes  dealing  with  some  important  aspects  of  the 
system,  like  data  transmission,  expected  development  risk  and  so  on;  to  be  effective  the  prototypes 
shall  be  prepared  in  short  time  and  shall  not  suffer  too  much  of  the  incomplete  and  generic 
information  available  of  the  early  stages  of  the  development. 

Although  the  use  of  rapid  prototyping  may  be  proven  useful  in  several  stages  of  the  system 
development,  its  main  application  can  be  found  in  the  steps  between  the  operational  concept 
definition  and  the  build  of  the  system.  Rapid  prototyping  is  intended  to  fill  the  gap  between  the 
weapon/overall  system  concept  and  requirement  definition  and  the  actual  design;  moreover  it  can 
complement  the  formal  description  methods  in  the  design. 

In  the  concept  exploration,  feasibility  and  definition  steps  the  design  team  shall  relay  almost 
only  on  its  experience  and  skill,  which  guarantees  in  most  cases  the  success  of  the  product. 
However  that  approach  is  not  an  organized  and  well  supported  way  to  proceed  and  sometimes  has  not 
given  the  best  results;  this  in  our  opinion,  was  mainly  due  to  the  lack  of  development  tools 
suitable  to  provide  clear  advices  on  problems  cluttered  in  an  highly  complex  environment.  The 
conventional  approach  does  not  help  very  much,  because  of  need  a  high  number  of  information  to  work 
effectively  and  the  available  operations  research  tools  are  focused  mainly  on  other  aspects  of  the 
system. 

The  rapid  prototyping  can  be  very  effective  also  in  the  final  stage  of  the  definition  and  design, 
when  the  information  can  feed  a  formal  description  of  the  system. 

In  fact  on  overall  view  of  the  most  important  aspects  of  the  architecture  and  functioning  can 
highlight  some  interaction  problems  and  requirement  misunderstandings.  An  early  correction  of  those 
errors  can  avoid  a  large  resource  expediture  to  correct  them  later  when  the  hardware  is  already 
build  and  the  software  coded.  In  short,  rapid  prototyping  reduces  the  forward  and  backwards  loops 
in  the  development  life  cycle  (see  para.  2.1). 

Let  us  consider  now  the  implementation  of  the  method;  key  features  are  the  rapidity  in  preparing 
the  prototype,  the  flexibility  in  modifying  it,  the  heustic  approach  in  treating  the  available 
data,  a  "requirement  oriented"  description  of  the  system. 

The  rapidity  is  needed  because  of  the  quick  reaction  time  usually  required  during  the  early 
development  stages  and  the  flexibility  allows  for  a  comparison  of  several  possible  solutions. 
Heuristics  helps  when  only  few  basic  information  are  available,  specially  if  they  are  expressed 
only  as  requirements. 

All  above  characteristics  cannot  be  found  in  the  conventional  simulation  computer  tools,  the  basic 
toolset  for  the  preparation  of  the  project-dedicated  prototypes  can  be  better  derived,  in  our 
opinion,  from  the  Artificial  Intelligence  machines  and  software.  The  Artificial  Intelligence,  as  a 
scientific  discipline  has  been  developed  about  thirty  years  ago  in  the  University  .  It  created  many 
expectations  and  resulted  in  some  disillusionments,  sometimes  due  to  the  lack  of  the  necessary 
technology  background. 

However  in  the  last  few  years  the  tools  created  expressely  for  this  new  discipline,  its  techniques 
and  methods  (in  particular  expert  systems)  gained  popularity  and  favour  in  the  industry  as  an 
applied  technology  suitable  for  interesting  applications.  Certainly  that  is  due  to  the  results 
obtained  but  also  to  the  holistic  approach  and  the  intrinsic  capability  to  organize  the  complexity, 
featured  by  the  Artificial  Intelligence  tools  and  techniques. 

The  AI  methods  have  all  characteristics  required  for  the  rapid  prototyping  and  more,  the  capability 
to  dominate  the  complexity.  To  dominate  the  complexity  means  to  have  structures,  methods, 
techniques  apt  to  organize  the  knowledge,  which  is  often  heuristic,  multivariate,  sparse  and  non 
homogenous,  unstructured. 

That  capability  is  intrinsic  because  AI  is  based  on  the  knowledge  and  it  consists  in  knowledge 
manipulation.  This  extra  feature  is  not  unnecessary  but,  on  the  contrary ,  could  be  a  need  because 
most  of  the  applications  of  rapid  prototyping  are  required  by  large  and  complex  systems,  where  the 
conventional  simulation  and  the  model  created  by  the  designer  in  his/her  mind  are  no  more 
sufficient  for  a  successful  design. 

Based  on  the  above  it  can  be  inferred  that  the  most  challenging  applications  of  rapid  prototyping 
methodology  shall  be  based  on  the  AI  tools,  like  LISP  machines,  knowledge  engineering  environments, 
which  can  ensure  the  necessary  flexibility,  complexity  treatment  capability  and,  being  "rule 
based",  can  offer  a  "requirement  oriented"  description  of  the  system. 

In  the  following  chapter  it  will  be  described  a  design  tool  for  a  specific  aspect  of  a  system,  the 
information  flow  architecture.  The  tool,  called  ECATE  (Expert  Consultant  for  Avionics  System 
Transformation  Exploitation),  has  been  developed  and  it  is  used  by  the  Avionics  System  Group  of 
Aeritalia  and  it  is  based  on  a  computer  and  a  software  expressely  conceived  for  the  Artificial 
Intelligence.  The  example  will  highlight  an  important  aspect  of  the  rapid  prototyping,  which  making 
use  if  AI  tools,  can  be  easily  associated  with  expert  systems,  another  useful  approach  to 
fu2zy  problems.  In  fact  ECATE  not  only  allows  to  prototype  architectures  but  also  can  give  advices 
on  its  optimization. 
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The  example  has  been  already  presented  in  similar  form  to  the  AGARD/AVP  Symposium  on  "The  design, 
development  and  testing  of  complex  avionics  systems"  | 3 | • 

Following  it  will  be  illustrated  a  more  complete  prototyping  environment,  that  can  be  used  at  a 
later  development  stage,  when  more  information  are  available  and  a  prototype  closer  to  the  final 
system  can  give  better  results. 


3.  An  example  of  rapid  prototyping 
3.1 .  General 


A  state-of-the-art  avionics  system  shall  be  fully  integrated  with  the  other  systems  of  the  aircraft 
and  shall  take  full  advantage  from  the  features  of  the  microelectronics,  to  provide  the  crew  with 
the  highest  mission  success  probability. 

It  means  to  find  a  real  implementation  for  concept  like  distributed  processing,  sensor  data  fusion, 
adaptive  reconfiguration,  expert  pilot  assistant,  synthetic  world  displaying,  now  made  possible  by 
the  advene emement  of  the  technology,  specially  the  data  processing  and  transmission. 

But  in  such  a  system  the  performance  increase  is  not  simply  due  to  the  higher  performances  of  the 
microcircuits,  on  the  contrary  it  derives  priraarly  by  an  increase  of  the  overall  system  complexity. 
In  fact  the  "black  box",  a  large  unit  with  well  defined  interface  and  function  allocation,  is  no 
more  the  basis  for  the  advanced  system  design  but  is  being  substituted  by  lower  scale  units,  which 
changing  combinations  provides  the  best  adptation  of  the  system  to  a  changing  environment. 

It  is  difficult  to  establich  a  metric  for  the  system  complexity  (see  for  example  ref.  |4j), 
however  it  could  be  said  that  it  is  reflected  by  the  amount  of  memory  used  for  operational  software 
storage,  which  today  is  increasing  to  a  rate  at  least  an  order  of  magnitude  higher  than  the  number 
of  other  microcircuits  in  an  avionics  system. 

The  increasing  complexity,  while  can  allow  for  dramatic  improvements  in  terms  of  reduced  pilot 
workload  and  mission  success  probability,  has  also  some  important  drawback. 

It  is  evident  that  a  complexity  which  is  mainly  software  implies  a  design,  development  and  testing 
process  and  a  management  of  it  much  more  difficult  than  in  a  conventional  system. 

3.2.  The  problem  of  the  system  architecture 

The  problem  considered  concerns  the  establishing  of  a  correct  data  flow  architecture.  There  are 
several  interpretation  of  the  term  "architecture"  in  the  avionic  system  design;  it  can  be  applied 
to  the  physical  structure,  the  topology,  the  software  organization  and  so  on.  All  these  are  aspects 
of  the  same  characteristic,  the  way  in  which  the  system  components  are  organized  and  work  together 
in  order  to  create  a  system. 

The  architectural  aspect  chosen  for  the  application  described  in  this  chapter  is  the  information 
handling  within  the  avionics,  i.e.  the  characteristics  of  the  data  flow  and  processing  among  the 
various  system  components,  considered  from  the  point  of  view  of  the  information  treatment. 

Therefore  the  following  definition  of  architecture  will  be  used: 

Definition 

System  architecture  is  the  organization  of  th«  information  generation,  distribution,  processing  and 
utilization  within  the  boundaries  of  the  avionics  system. 

A  pictorial  view  of  the  above  definition  is  given  in  fig.  5. 

The  boundaries  of  the  avionics  system  are  intended  to  define  the  meaning  of  generation  and 
utilization  of  the  information. 

In  other  words  if  the  boundary  identifies  the  world  outside  the  aircraft  all  information  coming 
from  it  corresponds  for  the  avionis  system  to  a  generation  of  information  for  the  avionics  system; 
on  the  other  side  the  data  are  utilized  when  they  are  provided  to  the  crew  on  a  display  or  to  the 
external  world  via  an  antenna. 

Such  an  architecture  is  relatively  easy  to  describe  by  means  of  few  building  blocks  with  a  limited 
number  of  peculiar  characteristics;  but  a  correct  design  of  it  has  relevant  influence  on  the 
overall  performance  of  the  system,  because  it  is  usually  established  in  the  very  early  stages  of 
the  design  and  it  is  difficut  to  be  drastically  changed  during  the  development  process. 

Therefore  it  is  clear  that  a  serious  error  in  the  data  flow  architecture  design  impairs  the 
achievement  of  the  design  objectives  in  terms  of  time,  cost  and  performance. 

For  that  reason  the  architecture  of  the  avionics  system  is  usually  designed  by  highly  experienced 
people  with  support  of  the  operations  research  tools  (see  ref.  |5|):  nevertheless  the  work  of  these 
people  is  difficult  to  quantify  and  to  describe  analitically ,  being  often  result  of  empirical 
knowledge  and  heuristics. 


Rapid  prototyping  of  a  complex  architecture  helps  to  easily  evaluate  many  alternatives  while  an 
expert  system  directs  the  search  for  the  best  design.  A  dedicated  tool  combining  together  the  two 
techniques  can  organize  and  manage  the  overall  complexity  of  an  architecture,  requiring  from  the 
operator  higher  level  decisions  only. 

A  tool  like  that  sketched  above,  described  in  the  following  paragraphs  and  developed  in  our 

laboratory,  can  be  of  effective  use  for  the  purpose  and  can  demonstrate  the  advantage  of  the 

Artificial  Intelligence  approach  in  the  rapid  prototyping  of  complex  avionics  systems. 

3.3.  System  description 

The  building  blocks  that  shall  be  used  for  the  construction  of  an  object  oriented  data  flow 

architecture  have  characteristics  that  describe  mainly  their  attitude  with  respect  to  the 

information  handling. 

Four  types  of  objects  represent  the  building  blocks. 

1.  Generators,  the  sensors  of  the  system,  the  controls  available  to  the  rew  and  the  interface  to 

other  systems. 

2.  Processors,  signal  processors,  mainly  associated  with  sensors  and  displays  and  data  processors 

to  elaborate  information  at  an  higher  level. 

3.  Utilizers,  displays  for  the  crew,  interfaces  to  other  systems,  emitters  or  weapon  which 

stimulate  the  external  world. 

U.  Channels  transmission  means  that  link  together  all  above  objects  when  not  directly  interfaced 
(aggregation  of  objects). 

Table  1  lists  an  example  of  the  typical  characteristics  associated  to  the  objects. 

It  shall  be  pointed  out  that  the  characteristics  may  vary  in  relation  with  some  peculiarities  of 
the  described  system. 

The  processors  and  the  channels  are  possibly  multiport  devices,  while  equipment  like  a  nonostatic 
radar  may  be  described  by  a  signal  processor,  a  generator  and  an  utilizer,  that  is  an  aggregation 
of  objects. 

Although  not  directly  related  to  a  technology  solution,  the  objects  that  form  a  system  architecture 
from  the  point  of  view  of  the  information  handling,  shall  nevertheless  take  into  account  the 
state-of-the-art  to  avoid  a  design  perfect  but  not  feasible. 

The  build !ng  blocks  shall  be  combined  to  form  the  information  handling  architecture  corresponding 
to  the  functional  architecture  to  model. 

The  architecture  is  characterized  by  some  features,  i.e.  system  descriptors  which  are  listed  in 
table  2. 

Some  descriptors  need  explanation  on  its  uefinition,  while  the  calculation  methods  are  embedded 
into  the  tools  and  will  be  described  in  para.  3.6. 

Risk  The  development  risk  take  into  account  how  much  each  object  is  close  to  its  technology  limit 
and  how  the  the  combination  of  objects  influence  the  development. 

Integration  level  It  takes  into  account  how  good  is  the  processing  within  the  system.  An  higher 
integration  level  is  a  merit. 

Growth  Capability  Represents  the  dual  of  the  resource  utilization  of  processors  and  channels. 

It  shall  be  noted  that  the  descriptors  can  be  computed  also  for  a  limited  portion  of  the  system,  a 
subsystem. 

3.^.  Rapid  prototyping  and  expert  system  design 

A  rapid  prototyping  tool  shall  assist  the  user  to  convert  from  the  functional/performance 
requirements  to  a  description  that  uses  the  object  and  connections  illustrated  in  para.  3.2. 

But  an  easy  means  to  prototype  many  alternate  design  solutions  is  not  sufficient  because  the 
knowledge  behind  the  architectural  design  is  not  totally  conveied  by  analytical  descriptors. 


Therefore  an  expert  system,  a  tool  that  allows  to  acquire,  use,  modify  and  make  available  a  type  of 
knowledge  which  is  complex,  difficult  to  transfer,  empiric,  incomplete  and  heritage  of  a  limited 
number  of  people  is  the  most  appropriate  supplement  for  the  rapid  prototyping  tool. 

The  expert  system  shall  direct  the  search  for  a  better  architecture  and  provide  advice  on  solution 
that  may  also  not  have  different  descriptor  values  but  are  known  to  guarantee  an  higher  confidence 
of  success. 

The  operational  flow  of  an  architectural  design  carried  out  by  means  of  a  rapid  prototyping  expert 
system  is  skectched  in  fig.  6. 


3.5.  The  tool,  ECATE 
3.5.1*  The  environment 

The  tool,  foreseen  by  para.  3-**  and  called  ECATE  (Expert  Consultant  for  Avionics  system 
Transformation  Exploitation),  has  been  developed  by  means  of  KEE  (Knowledge  Engineering 
Environment,  TM  by  Intellicorp) ,  running  on  a  dedicated  LISP  workstation  (EXPLORER,  TM  by  Texas 
Instruments) . 

KEE  is  a  development  environment  prepared  for  Expert  System  construction,  it  could  be  considered  an 
hybrid  tool  built  on  a  range  of  state-of-the-Art  Artificial  Intelligence  techniques  utilized  to 
combine  different  type  of  knowledge. 

TTie  knowledge  is  organized  in  frame/units  associated  to  which  are  their  peculiar  characteristics, 
that  structure  is  particularly  suitable  for  the  description  of  our  problem  because  it  implements  a 
programming  oriented  to  object  linked  by  relations. 

By  means  of  KEE  it  has  been  implemented  the  following: 

1.  The  user  interface 

2.  The  collection  of  objects  and  relations  that  represent  the  system 
3-  The  algorithms  and  procedures  for  the  descriptors  computation 

4.  The  expert  knowledge 

5.  The  knowledge  handling  structure. 

The  knowledge  about  the  system  is  acquired  via  a  graphic  interface  and  processed  by  the  inference 
mechanisms  embedded  in  the  KEE  environment,  according  to  the  set  of  rules  describing  tne  expert 
knowledge. 

3.5.2.  The  structure 

The  structure  of  the  tool  can  be  described  by  means  of  the  block  diagram  shown  in  fig.  7. 
Hereafter  follows  a  brief  description  of  the  main  components  of  the  structure. 

User  Interface  The  user  interface  assists  the  user  to  represent,  his  system  in  accordance  with 
convention  of  the  formal  description  and  is  formed  by: 

a)  graptiic  utilities  using  icons,  representing  the  objects,  with  associated  menus 
for  describing  their  characteristics. 

b)  indicators  of  the  system  descriptors  of  the  terminated  system. 

c)  menu  sensitive  "pushbuttons”,  i.e.  means  to  activate  a  "method"  (see  below). 

Methods  The  methods  are  procedures  codified  in  LISP  to  execute  algorith-  object  interaction  and 
reasoning/control  stategies  (see  table  3  for  example  of  methods). 

Permanent  data  base  It  contains  the  description  of  the  four  types  of  objects  and  their  classes  . 

It  contains,  moreover  the  expert  system  rule  base,  unmodifiable  by  the  user. 

Working  area  It  is  formed  by  the  units,  which  characteristics,  called  "slots",  describe 

all  information  about  the  system  ur*rff»r  development. 
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Inference  structure  This  structure  is  formed  by  an  inference  engine  operating  on  the  rules. 

The  structure  and  the  development  environment  allow  for  the  maximum  flexibility;  to  change  the 
object  and  system  descriptors*  inference  rules  or  methods  is  extremely  easy  for  the  expert  system 
designer.  That  feature  is  of  capital  importance  and  is  used  currently  because  the  tool  shall  evolve 
with  the  available  knowledge. 


3.5.3-  Consulting  ECATE 

The  steps  of  a  consulting  session  are  summarized  in  fig.  8  and  briefly  explained  hereafter. 

Configuration  Insertion  The  user,  with  assistance  of  the  tool  graphic  facilities  inserts  the  a 
configuration  of  objects,  aggregations  and  relations  he  wants  to  prototype 
(see  for  example  fig.  9). 

Compatibility  verification  The  tool  verifies  after  each  input  its  compatibility  with  the  objects 
related  to  it. 

Overall  Compatibility  When  the  configuration  is  complete  the  activation  of  the  "terminated  system" 
push-button  start?  a  verification  of  the  overall  architecture  compatibility. 

The  results  of  the  step  above  can  be: 

1.  Request  for  more  information  (for  example  some  relation  is  lacking  or  some  data  are  r.ot 
available) 

2.  Display  of  incompatibility  warnings  at  system  level  (for  example  a  multipoint  channel  of 
insufficient  capacity). 

3.  Satisfactory  compatibility 

Descriptors  computation  When  the  system  compatibility  is  not  violated  a  method  is  activated  *0 
compute  all  system  descriptors  for  which  sufficient  information  is 
avai iable 

The  results  of  the  previous  step  can  be  displayed  (see  fig.  10.)  in  either 
the  numerical  or  hystogram  format. 

ECATE,  by  means  of  rules  activated  in  forward  chaining  inference  presents 
to  the  user  advices  on  possible  architecture  problems  and  suggested 
changes  involving  objects,  aggregations,  subsets  or*  the  overall  system. 

The  user  can  ask  for  assistance  in  optimizing  the  architecture,  advices 
are  given  in  this  sense. 

In  case  the  user  wants  to  follow  one  or  more  of  the  advices  he  can,  by 
means  of  a  pushbutton,  modify  the  configuration  and  restart.  t.ho 
consulting . 

The  usr-r  can  ask  at  any  time  information  about,  the  facts  that  hav-, 

activated  the  rules  and  generated  the  advices. 

The  tool  accepts  at  any  step  not  only  numerical  values  in  response  to  its  queries  but  also  gnr.rri- 
indications,  like  high,  low  etc. 

The  consulting  session  car;  be  terminated  at  any  time  and  the  results  saved  in  the  library. 

3.‘j./*.  Val  idation 

The  validation  of  a  tool  like  ECATE  shall  answer  to  two  kind  of  questions: 

a)  Is  the  tool  conform  to  its  specification? 

;.  :  Is  the  tool  suitable  for  its  purpose? 

ror  the  first  check  ECATE  has  been  submitted  for  evaluation  to  the  experts  who  concurred  in  its 

dev  ! opine nt  and  to  foreign  experts,  exercizing  it  by  means  of  test  cases. 

The  second,  check  is  much  more  difficult  vo  perform,  because  it.  is  supposed  to  require  a 

demonstration  of  the  development  of  different  archi tectures,  accepted  or  rejected  by  ECATE. 


Result  display 


Optimization 


Assistance  request 


Configuration  change 


Explanation 


The  validation  has  been  completed,  the  results  available,  show  a  good  agreement  with  the 
predictions. 

Nevertheless  it  shall  be  pointed  out  that  the  high  flexibility  allowed  by  the  development 
environment  and  the  tool  structure  stimulate  a  continuous  refinement  to  adapt  ECATE  to  new 
situations  or  to  increase  its  knowledge.  It  is  in  fact  current  practice  to  introduce  new  object 
descriptors,  computing  methods  or  inference  rules. 

Therefore  also  the  validation  is  continuing  to  follow  the  evolution  of  ECATE. 

3.6.  Example  of  application 

In  this  paragraph  it  is  shown  an  example  of  an  architecture  to  illustrate  how  looks  like  the  system 
results . 

Fig.  11  shows  how  the  tool  allows  to  represent  the  sketch  of  the  system  prepared  by  the  designer. 
3.7  A  Future  Avionics  System 

At  the  moment  we  believe  that  the  knowledge  available  on  future  avionics  system 
architecture,  (see  ref.  |6|),  is  not  sufficient  to  effectively  use  ECATE. 

Reason  is  mainly  because,  although  enough  data  on  sensors  and  processors  can  be  found,  the 
knowledge  lacks  in  the  isplay  and  control  area  and  specially  on  standardized  multipoint  channels, 
switch,  backplane  and  .  igh  speed  data  bus.  Insufficient  is  also  the  knowledge  of  the  rules  that 
regulates  the  overall  s;  stem  functioning. 

Nevertheless  data  are  gathered  and  trials  are  performed  with  reference  to  experimental  data  to 
allow  the  specific  ECATE  knowledge  to  improve. 

4.  An  environment 


4.1.  General 


The  example  described  in  the  previous  paragraphs  deals  with  a  particular  aspect  of  the  system 
definition  activity,  the  tool  used  for  the  prototyping  is  a  LISP  machine,  a  computer  for  the 
Artificial  Intelligence  applications. 

By  means  of  the  above  said  computer  a  software  prototype  of  the  system  can  be  prepared  ar.d 

submitted  to  the  designer's  judgement,  supported  by  an  expert  system. 

However,  when  a  more  complete  view  is  needed,  a  deeper  definition  is  required,  for  instance  in  the 

design  phase,  or  the  results  shall  be  examined  and  commented  not  only  by  the  design  team,  but  also 

by  other  people,  the  Customer  for  example,  a  software  prototype  only  is  not  adequate. 

Other  resources  are  required  to  be  able  to  develop  and  validate  in  short  time  the  prototype  and, 
above  all,  to  use  it  effectively  and  to  present  the  result  in  a  suitable  way. 

Main  purpose  is  to  show  how  the  avionics  will  operate  in  its  environment,  internal  and  external  to 
the  aircraft,  when  designed  and  implemented  according  to  its  requirements  and  defined  architecture. 
From  the  above  it  arises  the  need  to  have  a  displays  and  controls  simulation,  a  real  tine 
capability  and  an  evaluation  mechanism  embedded  into  the  prototype. 

The  result  of  the  integration  of  those  resources  in  a  rapid  prototyping  development  environment 
(RAPIDE)  will  be  described  in  the  following  paragraphs. 

4.2.  The  Tool 


The  components  of  a  rapid  prototyping  development  environment  are  the  following: 

-  man/machine  interface  simulating  the  displays  and  controls  system  of  the  aircraft. 

-  real  time  aircraft  and  scenario  simulation 

-  object/rule  based  description  of  the  system 

-  evaluation  and  consultat-' on  facilities. 

Main  requirements  are: 

-  full  integration  of  the  components 

-  user  friendly  interface 

-  modularity  and  flexibility 

-  easy  expandability  and  interfacing  to  other  computers. 


\ 


The  above  listed  characteristics  may  resemble  an  aircraft  flight  simulator,  but  the  intent  in 
different,  more  complete  in  the  scenario  and  system  simulation,  less  in  cockpit  and  fl  ight  dynamics. 
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A  typical  implementation  of  the  tool  sketched  above  is  shown  in  the  block  diagram  of  figure  12. 
Major  components  are: 


-  the  interconnecting  network 

-  the  computing  nodes 

they  are  described  in  the  following  paragraphs. 

4.2.1.  The  Interconnecting  network 

The  interconnecting  network  is  the  backbone  if  an  integrated,  highly  modular  tool.  It  is  a 
fundamental  choice  because  it  shall  have  at  the  same  time  an  high  modularity  and  expandibility  and 
the  capability  to  manage  the  data  in  real  time.  A  suitable  solution  is  a  mix  of  a  bus  system,  in  a 
widely  available  standard,  plus  dedicated  high  speed  links  where  an  higher  data  transfer  rate  is 
required.  This  choice  ensures  an  high  compatibility  and  expandibility  by  the  use  of  a  local  area 
network  system  and  an  excellent  real  time  capability  where  and  if  required,  to  obviate  to  the  data 
transfer  rate  limits  of  the  most  populare  LAN  implementations.  All  hardware  and  most  of  the 
software  is  available  on  the  market,  only  part  of  the  software  is  dedicated. 

4.2.2.  Computing  modes 

4. 2. 2.1.  Artificial  Intelligence  workstation  (Central  Node) 

The  central  node  that  coordinates  the  environment  functioning  is  the  AI  workstation  (one  or  more 
for  complex  applications). 

On  that  computer  the  operator  manages  all  the  resources,  controls  the  development  of  the  prototype 
and  make  it  work.  On  the  workstation  itself  resides  the  kernel  of  the  system  prototype,  i.e.  the 
rules  and  the  objects,  and  the  real  time  data  base  of  the  network.  The  reason  for  the  use  of  the  AI 
tools  and  techniques  has  been  already  explained  in  the  previous  paragraphs;  furthermore  it  allows 
the  compatibility  with  less  demanding  applications.  The  workstation  provides  also  an  easy  way  to 
develop  and  evaluation  an  consulting  tool,  for  example  an  expert  system,  that  based  on  experience 
and  heuristics  can  give  useful  advices  on  the  system. 


4. 2. 2. 2.  Graphic  system 

In  order  to  provide  a  simulation  of  the  displays  and  controls  of  the  weapon  system  it  is  used  a 
graphic  system,  formed  by  a  workstation  and  satellite  units. 

The  display  formats  and  control  logic  are  developed  in  a  graphic  form  on  the  workstation  and 
activated  under  control  of  the  central  node  on  the  satellite  units  arranged  to  simulate  the 
aircraft  cockpit.  A  visual  simulation  of  the  scenario  is  not  strictly  necessary  but  often  can 
improve  very  much  the  understandability . 

4. 2. 2. 3.  Simulation  facilities 

The  system  and  its  environment,  the  weapon  system  and  the  scenario,  shall  be  simulated  by  means  of 
dedicated  computers.  The  "intelligent"  part  of  system  simulation  resides  in  the  central  mode,  but 
for  a  specific  implementation  the  simulation  of  an  aircraft  and  its  weapons  resides  on  a  powerful 
real-time  computer.  The  scenario  simulation  can  be  implemented  on  a  different  computer  because, 
usually  it  dr-'s  not  require  stringent  real  time  performances  but  it  needs  a  large  data  base. 

The  reel  time  computer  can  be  used  also  for  data  acquisition  and  stimulation  in  case  part  if  the 
system  be  available  in  hardware  and  its  use  more  convenient  that  the  corresponding  simulation. 

4.2.3.  An  Implementation 


An  implementation  of  the  environment  described  above  is  under  development  by  the  Avionics  System 
Group  of  Aeritalia.  The  main  component  are  the  following: 

-  an  Ethernet  network  with  TCP-IF  protocol 

-  T.I.  Explorer  LISP  workstation 

-  IFI3  graphics  system 

-  Gould  32/97  and  VAX  8500  computers. 


All  component  of  the  environment  has  been  already  connected  and  tested,  t.he  basic  software  in  ready 
and  a  limited  clearance  has  been  given  to  start  with  the  first  application. 
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5.  Conclusions 


The  benefits  of  rapid  prototyping  methodology  do  not  need  to  be  demonstrated.  An  early  availability 
of  a  prototype  of  the  system  avoids  late  modifications  of  the  implementation,  in  particular  when 
the  application  is  so  complex  to  make  difficult  its  complete  and  comprehensive  understanding. 
Current  issues  in  achieving  the  goal  of  rapid  prototyping  are  mainly  related  to  the  treatment  of 
the  complexity  and  its  description.  It  is  our  belief  that  a  suitable  solution  can  be  found  by  using 
the  Artificial  Intelligence  tools  abd  techniques  that  are  now  widely  available  for  industrial 
applications. 

Those  methodologies  cannot  be  used  for  every  aspect  of  the  prototyping,  conventional  simulation  is 
still  useful,  but  they  shall  be  the  key  point  of  the  application  because  they  can  treat  knowledge 
structures,  heuristics  and  uncertainly,  which  characterize  the  complexity  of  large  systems  iun 
their  early  design  stages. 

Important  is  moreover  the  fact  that  an  A  I  based  prototyping  can  easily  evolve  in  an  expert  system, 
that  can  assist  the  design  team  in  his  work. 

The  above  said  approach  has  been  demonstrated  effective  by  realizing  a  rapid  prototyping  and  expert 
system  dealing  with  the  data  flow  architecture  of  the  avionics  system,  a  tool  that  is  evolving  in 
a  full  development  environment  for  the  prototyping  of  all  major  aspects  of  an  avionics  system. 

We  are  confident  that  the  implementation  of  the  rapid  prototyping  by  means  of  the  knowledge 
management  techniques  can  be  a  significant  step  in  the  system  engineering. 
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(OEFUN  TOT-COST  (SYS) 

"Total  cost  computation  function." 

(PUT. VALUE  SYS  ’TOTAL-COST 

(SUMMA  'COST  (FIND-CHILDREN  'COMPONENTS  5Y5) ) ) 

(BREAK -LIST  (FIND-CHILDREN  'COMPONENTS  SYS)  'COST  'TOTAL-COST  SYS)) 


(DEFUN  TOT-INLEVEL  (SYS) 

"System  integration  level  determination. " 

(LET  ((LIST-PROC  (LIST-CONTROL  (FIND-CHILDREN  'PROCESSORS  SYS)  NIL))) 
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(PASSED-LIST  NIL)) 

(LIST-UT I -CONTROL  BIGLIST  PASSED-LIST)))) 
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(SUMMA  'INPUT-INFORMATION-FLOU  LIST-PROC) 

(GET. VALUE  SYS  ' TOTAL -DATA-FLOW) ))))) ) 
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RESUME 


Les  systemes  avioniques  militaires  representent  aujourd'hul  la  moitle  du  cout  de  1' avion  d'armes 
moderne  et  atteignent  de  tres  hauts  nivtaux  de  complexite  et  d 'integration .  Leur  developpement  necessite 
la  mlse  en  place  d'une  methodologie ,  supportee  par  des  outils,  prccisant  notamment  les  taches  et  produits 
associes  aux  differentes  etapes  de  specification  et  de  conception. 

En  particulier,  le  developpement  du  logiciel  de  ces  systemes  requiert  une  documentation  de 
specification  fonctionnelle  abondante  et  souvent  cortractuelle . 

Le  maquettage  de  ces  specifications  permet  : 

-  d’ameliorer  la  quallte  formelle  des  specifications 

-  de  reallser,  tres  tot  dans  le  cycle  de  vie,  une  validation 

-  de  fournir  des  elements  de  recette  pour  les  sous-ensenbles 

-  de  disposer  d’une  reference  fonctionnelle  commode  lors  de 
equlpements  reels. 

Le  maquettage  eat  une  technique  de  validation  prevue  dans  la  methodologie  et  utilisee  u  l'etapc 
de  specification  fonctionnelle  detaillee  selon  le  scenario  suivant  : 

-  ecrlture  des  specifications  detaillees  (langage  semi-formel) 

-  analyse  critique  des  specifications  contrSle  de  forme 

-  generation  du  code  maquette  et  implementation  dans  l^outil  de  maquettage 

-  tests  fonctionnela  sur  maquette  :  controle  de  fond 

-  fourniture  aux  realisateurs  d’equipements  de  specifications  validees  et  de  Jeux  de  tests  associes 

La  communication  abordera  de  facon  detaillee  : 

1  -  Le  contexte  methodologlque  dans  lequel  s'inscrlt  le  maquettage  (rappel  des  etapes  du  developpement  des 

systemes,  description  des  ateliers  systemes  et  ateliers  logiciels,  etc...) 

2  -  Les  experiences  realisees  au  sein  de  la  societe  Avions  Marcel  Dassault  -  Breguet  Aviation,  par 

l’analyce  et  la  synthese  des  travaux  de  maquettage  effectues  dans  le  cadre  des  systemes  avioniques 
Rafale  A  et  MIRAGE  2000  NC.  I’accent  sera  mis  d’une  part  sur  la  mise  en  oeuvre  pratique  du  maquettage 
des  specifications  et  les  r£sultats  obtenus,  d’autre  part  sur  les  utilisations  connexes  de  la  maquette 
en  tant  que  : 

-  support  d’ analyse  de  pannee 

-  banc  d'essals  pour  lea  evolutions 

-  generateur  d* elements  de  recette 

-  reference  fonctionnelle  pour  tous  lea  intervenants 

3  -  Les  tendances  pour  les  maquettages  futurs  (particulierement  pour  le  developpement  du  Rafale  D)  en  ce 

qui  concerne  notannnent  la  representativite  de  la  maquette  (temps  reel,  ergonomie,  etc...),  la 
generalisation  du  maquettage  aux  differentes  couches  de  specifications  et  1 'evolution  des  outils 
utilises . 

1  -  INTRODUCTION 


nnelle  de  ces  specifications 
me 

r-graticr  et  de  la  mlse  au  point  des 


Les  systemes  avioniques  militaires  atteignent  aujourd'hul  un  tres  haut  niveau  de  complexite  et 
representent  la  moitle  du  coGt  de  1* avion  d’armes  moderne. 

L'evolution  de  ces  systemes  au  cours  des  deux  dernieres  decenrites  peut  s’anaiyser  sur  les  plans 
uperationnels,  technologiques  et  methodologlques 

-  L'evolution  op£rationnel le  est  liee  a  1 'accroissement  de  la  polyvalence  des  systemes  qui  se  traduit 
par  une  plus  grande  richesse  op£rationnelle ,  et  par  une  integration  de  plus  en  plus  serree  des 
fonctiona  au  sein  d'un  mSme  systfcme  et  entre  systemes  avion  ou  sol.  (Le  systeme  est  alors  la  r.cmne 
de  plusleurs  systemes  embarques  ou  systemes  sol).  A  l'origine  liraites  a  des  fonctlons 
op£ratlonnelles  traditionnelles  telles  que  navigation,  bombardement  alr/sol  et/ou  interception 
air/alr,  les  systemes  se  sont  enrichis  peu  a  peu  d’une  panoplie  de  fonctlons  specif iques  d'armementa 
sophistiques ,  de  dispositifs  de  guerre  electronique  ou  d*  £qtii  percents  de  reconnaissance. 


L* integration  de  ces  fonctions  est  rcaJisee  dans  le  but  d' obcen.tr  une  efficacite  c-perationnelle 
iraximale  par  : 

.  I 'optimisation  des  ressources  physiques  (capteurs,  actionneurs,  organes  de  traitement  de 
1* information)  grace  a  la  fusion  de  donnees  et  aux  reseaux  d'echanges  d' infortaations  entre  avions 
et/ou  infrastructures  terrestres  et  marl  tines. 

.  1' optimisation  des  resBources  humaines,  grace  a  une  ergonomie  particullerement  soignee  de 
l'lnterfacc  horame /machine ,  assurant  un  dialogue  de  haut  niveau  avec  lea  pilotes,  le  systeme 
selectionnant  lui-meme  les  informations  utiles  A  chaque  phase  de  la  mission  et  les  presentant  sous 
la  forme  synthetique  la  plus  appropriee. 

Le  caractere  hautement  evolutif  des  systemes  s'affirrae  de  plus  en  plus,  l'enveloppe  operational  le 
doit  pouvoir  evoluer  facllement  :  integrer  de  nouvelles  fonctlors  sans  modifier  la  mise  en  oeuvre 
operationnelle  des  precedences  ou  ameliorer  les  fonctions  pre-existnnt.es  au  travers  des  evolutions 
technologiques . 

L' evolution  technologlque  des  systemes  avioniques  se  traduit  principaleraent  : 

.  par  des  architectures  fonctionnelles  et  matericlles  de  plus  en  plus  complexes  integrant  des 
systemes  historiquement  independants  tels  que  raoteurs,  commandes  de  vol,  carburant  ou  f reinage  et 
systematisant  l'emploi  de  liaisons  numeriques  multiplexees  entre  equipements. 

.  par  1* introduction  massive  du  logiciel,  apportant  une  souplesse  et  une  ouverture  considerables 
mais  lnduisant  des  problemes  specifiques  dont  la  maltrise  s'avere  encore  aujourd'hui  difficile. 

Les  systemes  avioniques  embarques  actuel leroent  developpes  par  les  Avions  Marcel  Dassault  compertent 
plus  d'une  centaine  d'equirements ,  dont  la  moitie  est  fortement  numerisee  et  dont  la  majeure  partie 
esc  fonctionnellement  dependante  dc  logiciels.  I.e  volume  de  logiciel  systeme  embarque  se  chlffre  en 
mega-octet 8 ,  le  nombre  d' informations  echangees  entre  equipements  et/ou  modules  fonctlonnels  dc passe 
30.000  et  le  debit  d' inf ormation  sur  les  bus  r.vmeriques  est  de  plusieurs  mega-bits  par  seconde. 

I. Evolution  methodologique  est  la  consequence  necessaire  des  evolutions  cpt  rati onnelles  et 
technologiques  dans  le  but  de  conserver  la  maltrise  du  developpement  de  ces  grands  systemes.  Les 
grards  axes  de  cette  evolution  concernent  : 

.  l'approche  "systeme"  de  la  conception 
.  1' assurance  de  la  qualite  en  conception 
.  1 'organisation  industrielle  pour  le  developpement 
.  les  specificlces  du  logiciel 

.  I'outillage  informatique  d'aide  au  df vel eppement 

.  Approche  systeme  :  des  les  etapes  les  plus  awont  de  la  conception,  les  systemes  anciens  pouvaient 
Itre  decoupes  a  priori  en  entites  autonomes  telles  que  radio-communication,  radio-ravigation , 
commandes  de  vol,  controle  moteurs  ou  telles  que  radar,  centrale  aerodynamique,  etc...  chacune  de 
res  entites  faisant  l'objet  d’une  conception  separee.  L' integration ,  la  decentralisation  et  la 
ocirplexite  en  ont  modi  fie  les  regies  du  jeu.  La  conception  du  systems.,  tache  amont  des  tSches  de 
conception  d 'equipements ,  s’affirme  comme  etant  la  plus  lourde  et  la  plus  delicate.  Elle  s'appuie 
en  particulier  sur  des  techniques  d' analyse  fonctionnelle  aboutissant  A  des  architectures 
fonctionnelles  distinctes  des  architectures  materielles,  le  rSle  operationnel  de  chaque  "bolte 
noire"  ne  se  degageant  plus  de  fagon  evidente. 

.  Assurance  de  la  qualite  en  conception  :  La  qualite  du  produit  (particullerement  la  sGrete  de 
fonctionnement)  du  produit  est  davantage  dor.cntree  par  la  qualification  des  methodes  utilisees 
pour  son  developpement  qu'au  travers  du  produit  lui-meme.  les  documents  d' assurance  de  la  qualite 
des  systemes  ou  des  logiciels  dccrivant  pour  l'essentiel  des  methodologies,  sont  les  temoins  de 
cette  evolution. 

•  Organisation  industrielle  :  La  taille  des  systemes  actuels  implique  Ja  mise  en  common  des 
ressources  et  des  competences  reparties  dans  de  ncir.hreuses  societes  industrieiles .  (Le  nombre 
d * intervenauts  dans  le  developpement  d'un  systeme  aviouique  de  MIRAGE  2000  depasse  25.000...).  One 
nitthodologie  rigoureuse  sert  de  support  aux  nouvelles  organisations  industrieiles  et  permet  de 
detinir  les  tSches  et  responsabili te  de  tous  les  Intervenantp  en  renforgant  la  visibility . 

.  Les  specif icites  du  logiciel  :  Les  travaux  de  conception  du  logiciel  sont  de  metre  nature  que  les 
travaux  de  conception  du  systeme,  1' ensemble  devant  done  etre  le  fruit  d'une  demarche 
methodologi que  continue.  En  consequence,  les  methodologies  de  developpement  des  logiciels  doivent 
etre  coherences  de  la  methodologie  de  developpement  du  systeme. 

*  L'outillage  informatique  d'aide  au  developpement  :  Les  methodologies  de  developpement  sont 
supportees  par  des  outils  informs  ti.qoes  dkaide  A  la  conception  ou  A  la  validation,  regroupes  en 
ateliers,  l.'eirerger.ce  de  l'approche  systeme  cree  le  besoin  d'un  atelier  systeme,  eba pear. rant  les 
ateliers  logiciels  et  assurant  l'aide  a  la  conception  amont  des  systemes. 
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2  -  METHODOLOGIE  DE  DEVELOPPEKF.KT ,  ATELIER  SYSTEME  ET  ATELIERS  LOCICIEL 

Dans  ce  contexte  particulierewent  ^vclutlf,  la  soclete  dea  Avlons  Marcel  Dassault  -  Breguet 
Aviation  a  dG,  xi  partir  de  son  experience  des  systemes  et  en  consentant  de  lourds  lnvestlssements , 
s'adapter  rapidement  pour  conserver  sa  maltrise  des  systemes  avioniques  complexes  : 

-  En  creant  une  methodologie  de  developpement  de  systemes  qul  definit  les  taches,  prodults  et  moyens 
associes  a  cheque  etape  et  sert  de  base  a  I'assurance  quallte. 

-  En  definlssant  et  en  realisant  l'ateller  systcme  correspondant  constltue  d'un  ensemble  coherent 
d'outils  interconnect^  multi-utilisateurs  et  multi vers Ions. 

-  En  participant  a  la  definition  et  a  devaluation  des  ateliers  loglclel. 

La  branche  de  definition  ctapes  de  gauche  de  V  se  revele  cotraae  etant  la  plus  critique.  En  effet, 
s'inscrivant  dans  la  partie  amont  du  cycle  de  vie,  toutc  erreur  ou  imperfection  a  ce  niveau  est 
ampllfiee  au  cours  du  cycle  et  se  traduit  par  des  consequences  aval  couteuses  et  di fficiZement 
maltrisables .  De  plus,  les  prodults  issus  de  cette  phase  etant  encore  essentiellement  des  documents 
paplers,  la  perception  du  prcduit  final  a  traver9  ces  simples  documents  eat  delicate  et  problematique . 

E  TAPES  DE  LA  METHODOLOGIE 
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1  -  Definition  prellmlnalre 


Le  role  de  cette  etape  est  de  definir  le  cadre  et  les  hypotheses  du  developpement  grace  a 
une  analyse  des  missions  et  une  premiere  etude  de  1  *  organisation  du  systeme. 

L'analyse  des  missions  s'appufe  sur  diverses  etudes  qui  permettront  de  s'assurer  de  la 
faisabilice  globale  du  systeme.  Elle  se  concretise  par  une  liste  des  fonctlons  op4ratlonnelles 
necesaaires  a  la  realisation  de  l'enveloppe  des  missions,  et  fait  ressortlr  un  ensemble  de  besoins 
concernant  particuli^rement  les  principaux  capteurs. 

L'  etude  d  *  organisation  dr.  systeme  conduit  a  une  premiere  definition  de  l'architecture 
tnat£rielle  du  systems  (liste  d* equloements  et  d'emports,  organisation  materielle  du  poste  de 
pilotage,  etc...). 

2  -  Definition  globale  du  qysteme 

L'etape  de  definition  globale  consiate  a  definir  precisement  les  services  que  le  cysteine 
doit  rendre  (et  non  pas  comment  le  systeme  sera  construit). 

Le  resultat  de  l'etape  est  une  description,  en  terme  de  scenario  operationnel  (done  vu  de 
l'utlllsateur) ,  de  la  wise  en  oeuvre  et  du  f onctionnement  nominal  du  systeme  pour  toutes  les 
fonctlons  qu'il  assure.  Cette  description  se  tradult  par  deux  types  de  documents  : 

-  Documents  de  regies  generales  : 

Ces  documents  decrivent  de  fagon  unique,  les  regies  et  philosophies  d'utilisatlon  appllcables  a 
toutes  les  fonctlons  operationne1 les  dent  est  et  sera  dote  le  systeme.  11s  garantissent  ainsi 
une  mise  en  oeuvre  coherente  du  systeme  dans  tous  les  modes.  (Ex.  regies  generales  de  dialogue 
homme-machine ,  de  signalisation  des  pannes,  de  superposition  des  fonctlons,  etc...). 

-  Documents  de  specification  globale 

Chaque  document  de  specification  globale  decrit  le  scenario  d ' utilisation  du  systeme 
relativement  a  une  fonction  operationnelle  donnee.  Ch2que  fonction  operationnelle  fait  done 
l'objet  d'une  specification  qui  est  ecrite  dans  le  respect  des  regies  generales.  Ces 
specifications  etant  independantes ,  elles  peuvent  etre  elaborees  de  facon  autonome  ct 
asynchrone.  La  coherence  et  1 ' independatice  des  specifications  globales  sont  assurees  par  les 
regies  generales. 

Les  regies  generales  et  les  specifications  globales  sont  validees  grace  a  un  outil  d'aide  a  la 
specification  mettant  en  jeu  1'aspect  dynamique.  Cet  outil,  construit  autour  d'une  maquette 
representative  du  poste  de  pilotage,  permet  de  sitnuler  les  sequences,  cotrmandes  er 
visualisations  permettant  ain8i  une  validation  plus  efflcace  des  scenarios  par  les  pilotes 
utlllsateurs. 

2.3  -  Analyse  fonctjonnel le  et  architecture 

Le  role  de  cette  etape  est  de  proccder  a  l'analyse  fonctionnelle  du  systeme  et  d'en  deduire 
son  architecture  fonctionnelle.  Le  dossier  d'architecture  fonctionnelle  (produit  de  l'etape) 
decrit  la  solution  apportee  aux  besoins  exprimes  a  l'etape  de  definition  globale. 

L'etape  ae  decompose  en  deux  phases. 

-  La  construction  du  graphe  d'architecture  fonctionnelle 

La  methode  utlllsee  consiste  en  ur.c  decomposition  hierarchiquc  progressive  du  systeme  en 
elements  fonctionnels,  selon  des  criteres  precis.  Chaque  niveau  successif  de  decomposition 
entratne  : 

.  une  justification  du  decoupage  realist 

.  une  collection  systematique  des  interfaces  induites  entre  elements 

.  un  affinage  progressif  de  la  definition  de  ces  interfaces  par  rapport  au  niveau  de 
decomposition  immediatement  superieur. 

Le  graphe  fonctionnel  decrit  le  systeme  selon  une  arborescence  coherente  supportec  par  outil. 
I. 'ensemble  des  elements  terminaux  de  la  decomposition,  appeles  modules  fonctionnels,  et  de  leurs 
interfaces,  representent  1 'architecture  fonctionnelle  du  systeme. 

Les  contraintes  prises  en  compte  pour  1 'etablissement  du  graphe  sont  : 

.  des  contraintes  de  qualite  (particullerement  l'evolutivite)  qui  imposent  des  regies 
d 'independence  entre  modules  fonctionnels,  ou  des  contraintes  operationnelles  exprimees  dans 
les  documents  de  regies  generales.  l'analyse  de  ces  dernieres  permet  de  degager  la  structure 
du  "coeur  fonctionnel”,  ensemble  de  modules  de  gestlon  des  re9sources  du  systeme. 
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-  Projection  de  1  'arch! tecture  fonctionne He  sur  1 ’architecture  aaterielle 

Cette  phase  consist®  a  Integrer  1 1  architecture  fonctionnelle  prealablement  definie  et 
1 'architecture  aaterlelle  proposee  au  cours  de  la  definition  preliminaire.  les  modules 
fonctionnels  sent  alors  distribues  dans  les  Equipements  et  identifies  (matt-riel  cu  Icpiciel), 

Cette  projection  definit  le  compromis  d®  realisation  tenant  compte  de  plusieurs  facteurs  : 

.  des  facteurs  technologiques  :  selor.  Is  nature  des  traiteraents  a  effeciuer,  choix  de 
l'equipement  le  plus  adapte. 

.  1* optimisation  de  la  connectique  ;  on  recherche  une  distribution  des  modules  rainimiaant  le 
flux  d'echange  entre  equipements  et  privilegiant  "le  plus  court  chetoin"  pour  les  informations 
critiques  d*un  point  de  vue  temps  reel. 

.  des  facteurs  de  qualite  particulars  :  par  exempJe,  les  modules  supportant  des  fcnctions 
critiques  d'un  point  de  vue  securitd  seront  regroupes  dans  un  mine  rquipement  et/ou  redondes 
dans  plusieurs  equipements. 

.  des  facteurs  deterministes  de  savoir  faire  cu  d 1  organisation  industrielle 

2.4  -  Specification  fonctionnelle  detaillee 

L'etape  de  specification  fonctionnelle  detaillee  consiste  a  etablir  la  specification  des 
fonctions  de  transfert  de  chaque  module  fonctionnel  identifie  dans  1  *  architecture . 

Ces  documents  representent  la  derniere  etape  de  la  phase  de  definition,  directement  du  role 
et  de  la  responsabilite  de  I'avionneur.  Us  representent  la  reference  contractuelle  vis  a  vis  des 
cooperants  pour  la  realisation  du  logiclel  des  equipements.  II  faut  noter  que  la  modularite  de 
cette  documentation  (un  document  autonome  par  module  fonctionnel)  induit  une  contrainte  de 
realisation  aigfle,  l’architecture  logicielle  de  chaque  equipement  devant  respecter  le  decoupage 
Impose  par  1 'analyse  fonctionnelle  du  systeme. 

Idealement,  ces  documents  doivent  contenir  "tout  ce  qui  est  nccessajre  et  seulement  ce  qul 
est  neeessalre"  a  la  realisation  des  logiciels  et  des  matt-riels. 

C'est  a  ce  niveau  de  specification  que  nous  ressentons  un  besoin  constant  d'amelioration  de 
la  qualite  des  documents,  sur  les  plans  de  la  forme  et  du  contenu. 

les  methodes  et  outils  classiques  utilises  pour  l'ecriture  et  la  validation  des 
specifications  fonctionnelles  detaillees  sont  : 

-  L'utllisation  de  canevas  stricts  et  de  langagee  semi-formels 

-  la  standardisation  de  la  terminologie  par  le  biais  de  dictionnai res 

-  L'organisation  de  relectures  croisees  systematiques 

-  L'utllisation  d'outils  documentaires  (traitement  de  texte  (texte  +  graphique)  multiversion). 

Depuis  1985,  l'eventail  des  methodes  s'est  enrichi  de  la  technique  de  maquettage  des 
specifications  fonctionnelles  detaillees  qui  presente  l’avantage  d'assurer  a  la  fois  la  qualite 
formelle  de  la  specification  (par  necessite)  et  sa  qualite  "fonctionnelle"  par  effet  de  miroir. 

le  raaqueftage  fonctionnel  a  Ete  utilise  pour  la  premiere  fois  dans  le  cadre  du  programme 
RAFALE  A  a  l'etape  de  definition  fonctionnelle  detaillee. 

II  a  ete  reconduit  pour  le  developpement  du  systeme  N1RACE  2000  New  Cockpit  et  sera  applique  en 
vraie  grandeur  grSce  a  un  ensemble  d'outils  idoines,  pour  le  developpement  du  systeme 
ACE /RAFALE  D. 

2.5  -  Developpements  des  logiciels  et  materiels 

Les  developpements  specifiques  des  equipements  et  des  logiciels  sont  des  caches  avales  et 
consequentes  des  Etapes  de  developpement  du  systeme  regumees  plus  haut,  Ils  sont  confies  a  de 
multiples  Sous-traitants  et  concernent  les  etapes  de  developpement  suivantes  : 

-  Definition  fonctionnelle  du  logiclel 

-  Conception  globale  du  logiciei 

-  Conception  detaillee  du  logiclel 

-  Codagt  /  realisation  des  Equipements 

-  Tests  unitaires  du  logiciei 

-  Tests  d’ integration  du  logiciei 

-  Tests  fonctionnels  du  logiciei 

-  Tests  fonctionnels  de  l'equipement 

Remarque  :  les  methodologies  de  developpement  de  logiciei  a  partir  des  specifications  systeme 
ainsi  que  les  ateliers  logiciels  correspondents  peuvent  etre  sensiblement  differents  selon  les 
rEallsateurs. 

NEanmoins,  l'archltecte  industriel  du  systeme  dolt  s 'assurer  de  leur  adequation  a  la 
methodologle  de  developpement  du  systeme  par  des  audits  ou  a  travers  les  normes  appliquees  par 
chaque  rEallsateur. 


6  -  Prevalidation  fonctlonne lie  des  eguipements 

Le  but  de  cette  •-  tape  cr.t  de  proceder  a  une  evaluation  fonct  ionnelle  so  pares  do  chaque 
equipement  developpe  afin  d'aboutir  a  un  niveau  sutrisant  de  quail te  avant  integration  du  s\  r.tfrie. 

Le  principe  consiste  a  derouler  des  scenarios  fonrtiornels  a  1 'echelon  de  1 ' <'qui  pet.cnt  pour 
verifier  les  fonctlons  implantees  dans  I 'equipement  et  mesurer  diverret,  marges  de  t  once  ionn&meni 
(temps  de  trace  pour  un  equipement  de  visualisation,  charge  de  calctil  or  occupation  momoire  pour 
un  calculateur,  etc.,.). 

Les  scenarios  d'essais  utilises  peuvent  etre  issut,  de  sources  variees  ccmine  : 

-  Rcsultats  du  maquettage  des  specifications 

-  Scenarios  generes  au  moyen  du  hanc  d 1 i ntegrat ion  du  systeme 

-  Scenarios  enregistres  en  vol 

-  Simulations  d'environnemen*: 

Les  movens  utilises  pour  la  prevalidation  function el le  sort  multiples  :  movens  dt 
de ve l oppement s  sysltnc,  noyens  de  traitement  de  1 1  inf orration  et  outils  specifiques  ou  rl<. 

generation  d’trvironnement . 

?  -  Integration  et  verification  sur  banc  d 1  i nt-'-gyntl on  wsteire 

I.e  but  de  cette  etape  eat  de  s' assure  r ,  avant  integration  sur  avion,  d«-  la  i onfornite  <lu 
systeme  a  sa  definition  global e,  de  la  coherence  des  configurations  success i ves ,  et  u'e valuer  le 
romportement  du  systeme  dans  tout  son  dor.aine  d '  ut  i  li  sat  i  on  fdontaine  avion,  ca«-  de  p.moes, 
tolerance  aux  pannes,  ere...). 

Les  bancs  d  '  integration  per  met  tent  1  a  rise  on  oeuvre  aisee  des  equi  pent :  i  s  t  c  nst  1 1  uant  le 
systeme  et  de  la  panop)  ie  d'outils  d' integration.  Tls  posi-cdent  : 

-  ['ensemble  des  equipements  reels  du  systems  integre 

-  des  movens  de  surveillance  analogiques  et  nutr.eriques 

-  des  similateurs  d’interfaces  numeriquey  et  analepjeues 

-  une  ir.pl. an  tat  Ion  realiste  des  oquipements  do  dialogue  honme/machtre 

!  ’  envl  ronnement  du  systeme  avionique  emharque  cst  restltu.'  fi:r  >c  banc  grace  a  un  c^rh:>v 
informatique  permettunc  les  functions  de  sk  inula  tier  et  dr  .cirniiat  ion.  Ces  deux  fonctlons  c ::  i  pour 
but  de  gc-tifrer  or  ervi  ronnement  realiste  .'•oluaut  avec  la  rr.eme  dynamiqvu  d«-  ir;  r*’  *  res  cue  sur 
avion . 

-  La  stimulation  consiste  a  rejouer  sur  le  baric  ur.  scenario  enreginre  sur  avion  dr  f.i.t  ;.  :..ei  t  ri¬ 

le  systeme  dans  un  etat  idertictie  cclui  rencontre  en  vol 

-  La  simulation  consiste  a  gi-m:r«r  un  Kd'r.r.rfr  de  facon  interactive,  perr<i£..r.t  uinsi  Je  "pJhjter” 
le  systeme  et  d'etudler  ses  n'ponses  dans  tout  son  domaine  d  'ut  il  i  sat  i  on . 

Les  banc-  '"integration  permettent  aujourd'luit  de  proceder  a  la  plupari  de*  t?v*o  de 
”eri  f i«-at ion  et  de  qualification  des  systf-mes,  reservant  les  tests  «.i:  .uir  quelqucs  essai*; 

critiques  pour  lesquels  le  banc  n'est  pas  suf  f  i  sarr.ont  representaM  f . 

l.eurs  avantages  sont  lours  cout  et  souplesse  d  * »» t  i  1  i  sat  i  on  <compares  a  ceux  d'un  ssi-.i.  . 
leur  disponi  hi  1  i  tt  ,  leur  faclllte  devolution,  leur  actuellc  representat  i  v*  t  «t  »nf?:'  'our 
puissance  a 'analyse  sans  oesse  croissante. 

.H  -  inu  m  alien  c  i  verification  sur  avion 

l.e  hut  de  cetit  etape  cst  de  verifier  ft  de  gnrar.t  i  r  le  f  one  t  ionnement  «*p.'»rat  *  or.n  ;  u. 
systeme  einbarque.  I.  taches  se  composer r  d'essais  au  sol  et  d'essais  en  vol. 

Au  sol  sont  conduits  des  ossais  d '  integration  necessJtant  1 'avion  complet,  des  ess.i:>  !< 
maintenance,  ou  des  essais  dt  comport ement  electromagnet ique  rf-aHm's  dans  tir.e  ch.im.hre  ancchrTde . 

Frr  ve  3  sont  conduits  des  essais  d'ouverlurc  do  n-aine?,  des  essai^  de  separation  il'emperts, 
ler  c-isais  f  mu- 1 1  onne  1  s  complementui  rcr  des  essais  realises  sur  banc  d  '  i  r  r«‘  grat  loft  et  ent'in  des 
"’valuations  oper.it ? onnel  I <;s  p.in  .»  u'  ieres  la  dematule  de  1'nvionreur  '.ui-meme  ou  de  ses  cl  . 


Les  mover. s  utilises  sont  noifihretijj  et  varies,  suit  '.on  exliatisti  vement  :  les  avioi.s 
prototypes,  les  Installations  d'essais,  les  dispo«itjfs.  dt  t ..  1 »  mesure ,  les  sal  les  d'u-ii  U  , 
i  cmplezes  informat  forms  terj.s  rfei,  J  es  movens  de  preparation  cl  restitution  de  mission  et  K? 
d  i  ( :  >■  rent  s  matcriels  Je  mise  en  oeuvre  *r.  p  t  c  t  e  . 
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J  -  APPLICATION’  AU  RAFALE  A 
3.1  -  Contexte 


Le  systeme  avionique  de  1* avion  demons traceur  RAFALE  present*  un  certain  nombre  de 
nouveautes  et  do  specificites  par  rapport  aux  avions  de  la  generation  precedente,  telles  que  : 

-  L* integration  tres  poussee  incluant  les  systemes  avion 

-  L’extension  du  nombre  de  fonctlons  r.eeessaires  des  le  premier  vol 

-  La  decentralisation  des  fonctlons  aysretre  (reparties  dans  plusleurs  (quipements) 

-  La  generalisation  de  l’esplol  des  techniques  numeriques  dans  des  domalnes  ou  l'experience  en 
etait  faible 

-  Les  delais  tres  courts  et  tres  tendus  de  l'operation. 

Pour  feire  face  a  cette  situation,  il  a  alors  cte  decide  de  realiser  un  travail  dr 
maquettage  des  specifications  avec  les  objectifs  suivants  : 

a)  Atneliorer  la  qualite  des  specifications  fonctionnelles  detail  Ires 

b)  Pennettre  une  validation  fonctionnelle  de  ces  specifications 

c)  Fournir  aux  cecperants  des  jeux  d'essais  coherents  pour  valider  aussl  t6t  que  possible  lours 
developpemcnts 

d)  Disposer  d*un  banc  d'essai  pour  tester  a  priori  les  evolutions. 

Ce  travail  a  dehutc  en  (tars  85  avec  les  etapes  suivantes  ; 

a)  Analyse  critique  des  specifications 

b)  Realisation  de  la  maquette 

c)  Exploitation  de  la  maquette 

3.2  -  Analyse  critique  des  specifications 
i  -  But 


Les  specifications  fonctionnelles  dt'taillees  representent  la  charr.iere  entre  la  conception 
(travail  AMD-BA)  et  la  realisation  des  logiciels  (travail  des  cooperants).  II  est  done  important 
qu'elles  solent  a  In  foif  : 

-  Fntierement  representatives  des  besolns  operatlonnel a  du  cor.cepteur  (aspect  fonettonne) ) 

-  Comprehenslbles  et  realisable  par  les  cooperants  (aspect  fonael) 

Le  but  de  I'analyse  critique  des  specifications  est  d'atne) iorer  leur  qualite  pour  couvrir 
l'aspect  formel,  cVst-a-dire  s'assurer  que  les  specifications  sont  : 

-  lisibles 

-  completes 

-  coberentes  entre  elles 

-  sans  ambiguTte 

-  realisables  informatiquerert 

2  "  Principe  et  organisation 

Un  spec! flcateur  etant  naturel lement  satiszait  de  son  document  grace  ^  sa  ccrraissance  du 
contexte  operatlonnel ,  pour  one  1 'experience  soit  rentable  11  a  tallu  isoler  les  lecteurs 
critiques  de  ce  merae  contexte  en  lir.itant  les  explications  fournies  cui  les  specifications.  Le  mot 
d'ordre  a  etc  :  ne  pas  juger  de  ce  que  doit  faire  la  specification  ( fonctionnel )  mp.fr.  juger 
urlouerrent  la  maniere  dont  pile  est  ecrite  et  sa  faisabilite. 

L' equine  de  relecture  n'a  pas  tu  connalssancs  du  besoln  operatlonnel  exprime  a  t ravers  les 
specifications  detail  lees  (specifications  globales  non  fournies). 

La  totalite  des  documents  de  specification  delaillce  (3000  pages)  a  ete  soumise  a  1'equlpc 
de  relecture  critique.  Toute  fiche  devolution,  quelle  que  sot t  son  orlglne,  s'est  vuc  appliquer 
la  mere  procedure  de  relecture. 

3  -  Resultats  de  I'etape 


Le  nombre  de  critiques  (justifiees)  a  ete  ext  remcr.eul  important  :  25U  pages  de  ter..arquos, 
representaot  de  I'ordre  de  1000  points  precis. 

Le  nombre  de  critiques  par  page  de  specification  (done  in  fine  la  qualite  formelle  de  la 
specification)  varie  cons iderab lement  en  fonction  : 

-  du  re dacteur  (rigoureux/non  rigoureux,  precis/general ,  structure/collectionneur  de  details) 

-  dn  module  specifle  ( 1 ogique/algorithmique ) 

l.es  eneurs  relevees  par  la  critique  oitrcrt  routes  dans,  les  trots  ategories  ; 

-  erreurs  de  rigueut 

-  erreurs  de  prrerallte 

-  inadaptation  de  la  specification  a  une  realisation  1  nfomar  i  cue . 
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a)  Erreurs  de  rigueur 

-  Interface;  manquante  :  1' information  utilisee  par  lcs  traitements  n'est  pas  declare®  a 

entree  de  la  specification 

-  Interfaces  incoherences  r  les  interfaces  declarees  en  entree  du  module  specifie  n’exi6tent 
paa  dans  le  systeme  (non  calculees  par  d'autres  modules) 

-  incompletude  des  traitements 

.  Le  traitement  relatif  a  une  sortie  declaree  du  module  n’eat  pas  specifie 
.  Dans  une  combinaison  logique,  tous  les  cas  ne  sont  pas  renselgnes  ;  11  est  a  noter  que 
le  cas  est  tr£s  frequent  lorsque  la  logique  est  exprimee  au  moyen  de  phrases  (si,  alors, 
sauf,  quand)  et  pratiquement  lnexistant  si  la  logique  est  decrite  sous  forme  de  tableaux 
de  verite. 

.  Les  conditions  d 'initialisation,  d* activation,  d' enchalneaent  des  traitements  ne  sont 
pas  speclflees. 

-  Termlnologle  floue  ou  ambiglie 
Exemple  : 

"on  determiners  ..." 

"dans  la  plupart  des  cas..." 

"dans  certaines  conditions,.." 

"1 ' information  existe  dans  les  cas  suivants..." 

b)  Erreurs  de  general! te 

-  Caracterlstiques  d *  interfaces  non  speclflees 

Ne  sont  pas  precises  i'unite,  le  type  (logique,  booleen) ,  les  valeurs  possibles  d'une 
information. 

-  Traitement  decrit  trop  globalement  : 

O  genre  d'erreur  est  frequent  lorsque  le  specif icateur  surestime  le  savoir  faire  (ou 
l'intuitlon)  des  realisateurs  de  logiciel. 

c)  Inadaptation  de  la  specification  a  une  realisation  informatique 

-  Choix  de  la  solution  informatique  :  le  spec! ficateur ,  dans  un  louable  souci  de  rigueur 
impose  la  fagon  dont  doit  etre  realise  le  traitement  :  connaissant  peu  les  criteres  de 
"programmation7' ,  le  choix  est  parfois  non  astucieux  et  peut  deboucher  sur  un  logiciel 
demesure  ou  non  evolutif. 

U  -  Remarques  et  cotmnentaires  sur  l'etape  d*  analyse  critique 

L'etape  d'analyse  critique  des  specifications  a  etc  extremement  fructueuse  et  revelatrice, 
Nombre  de  problemes  de  toute  importance  ont  pu  etre  ainsi  resolus  a  priori,  evitanc  de  les 
reporter  a  la  phase  d 'integration.  f>ar  contre,  i'energie  mise  en  oeuvre  a  ete  egalencnt 
Importante  :  equlpe  de  relecturc,  temps  "vole"  aux  specif icateurs ,  lourdeur  de  mise  a  jour  de  la 
documentation . 

La  plupart  des  erreurs  recensees  sont  des  erreurs  evi  tables  qui  ne  remettent  pas  er.  cause 
le  profil  actuel  des  specif icateurs .  En  effet,  cette  phase  de  relecture  a  conduit  a  ameliorer 
une  specification  exlstante,  non  pas  a  creer  une  couche  de  specification  plus  detaiHee. 

Enfin,  l'experience  a  ete  vpeue  par  les  spec! ficateurs  comrae  un  controlc  qualite 
supplemental  re ,  done  ressentie  de  fagoq  tres  mitigee... 

3.3  -  Realisation  de  la  maquette 

1  -  Elaboration  des  programmfcs-r.aquette 

La  necessity  de  coder  lcs  specif Ications  a  mis  en  evidence  trois  imperatifs  d'ecrlture  de 
celles-ci.  Les  deux  premiers  sont  d'ordre  general  et  concernent  toute  specification  devant  etre 
codpe,  lc  trolsieme  est  lie  a  la  structure  doublee  du  systeme  RAFALE. 

Premier  imperatil  :  completude  des  Interfaces 

Dcuxleme  imperatif  :  definition  du  type  de  chaque  variable 

Trolsleme  imperatif  :  definition  pour  chaque  variable  du  type  de  liaison  entre  module  dmetteur 
et  module(s)  recepteur ( s) 

D'autre  part,  l'operatinn  de  codage  a  cenfirme  la  necessity  de  description  d *  an  Logiciel 
enveloppe  pour  chaque  nodule  lmplante  dans  un  equipement  double. 

C  ompletude  des  lr.t  erf  aces 

Cette  Ctape  est  indispensable  avar.t  toute  operation  de  codage.  Le  renseignement  complet 
des  Interfaces  a  done  tite  necessaire,  avant  codage  du  logiciel  initial,  cotnme  avant  chaque 
passage  d'une  version  a  1 'autre. 


I 
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Definition  du  type  de  chaque  variable 

Cet  imperatif  a  conduit  a  enrichlr  la  base  de  donnee  d' interfaces  avec  la  definition,  pour 
chaque  variable,  d'un  type  analogue  aux  declarations  de  variables  FORTRAN,  a  savoir  : 

-  Bool^en,  tableau  de  booleens,  loglque,  reel,  entier. 

Nota  :  La  phase  d’analyse  critique  des  specifications  avait  deja  fait  apparaltre  la  necesslte  de 
definition  du  type  de  variable. 

Codage  des  modules  fonctionnels 

Le8  programmes  maquette  ont  ete  ecrits  en  FORTRAN,  directement  a  partlr  de  la 
specification  (apres  phase  d'analyse  critique)  et  en  utllisant  la  base  de  donnee  d'lnterfaces 
comme  referenciel  des  variables. 

Produits 


Le  resultat  de  la  phase  d'elaboration  des  programmes-maquette  se  decompose  en  : 

-  Un  produit  intermediaire  sous  la  forme  d'un  fichier  de  variables  de  8  caracteres  extrait  de  la 
base  de  donnees  d 1  interfaces .  Ce  produit  constitue  en  fait  un  complement  de  specification, 
indispensable  pour  la  generation  du  code. 

-  Un  produit  final  compose  des  programmes-maquette  (ou  modules)  d’une  chafne  de  calcul. 
L'obtention  de  1' ensemble  des  modules  representatif s  des  deux  chalnes  devant  etre  faite  grace 
a  la  duplication  de  ces  programmes-maquette. 

2  -  Adaptation  de  la  console  de  visualisation  des  echanges  (CVE) 

La  CVE  etait,  a  l'origine,  un  outil  de  visualisation  des  echanges  entre  equipements 
numeriques.  Pour  les  besoins  du  maquettage,  il  a  fallu  faire  tendre  cet  outil  de  visualisation 
vers  un  outil  de  validation  de  specifications.  Les  travaux  d'adaptation  ont  porte  sur  : 

Au  niveau  conversatlcnnel 


-  Le  pilotage  de  la  simulation  (choix  du  mode  simulation,  des  modules  a  activer,  etc...) 

-  Le  developpement  de  procedures  d'entree  de  valeurs  a  la  CVE 

-  L' amelioration  de  la  gestion  des  chalnes  meworisees  (concatenation  de  chalnes,  appel  nominatif 
de  celles-ci) . 

-  Le  developpement  des  procedures  de  tests  automatiques 
Au  niveau  systetne 


-  La  generation  des  lexiques  CVE 

Ces  lexiques  sent  necessaires  au  bon  f enctionnement  de  la  simulation  et  a  Sexploitation  des 
rcsultats  de  celles-ci. 

Us  comprennent  : 

.  la  liste  des  modules  et  leurs  adresses 

.  la  correspondence  des  fichlers  8  caracteres  par  rapport  aux  fichiers  de  la  base  de  donate 
d 'interface  initiale  (40  caracteres) 

.  la  liste  des  paves  recepteurs  dfune  information  donne'e 

3  -  Mlse  ei  oeuvre  de  la  simulation 

Les  carnet  erf  stiques  essentielles  de  la  simulation  n.ise  en  place  sonL  les  suivarfes  : 

-  Simulation  mono-frequence 

-  Cycle  de  simulation  correspor.dant  a  l'activation  sequentlelJe  des  modules  maquettes 

-  Prise  en  compte  de  ] 'architec ture  doubl e-ch&tne  du  RAFALE  : 

Cette  prise  en  compte  se  resume  a  1 'etablissement  de  deux  procedures  : 

.  Eclatement  des  variables 
.  Duplication  des  programmer. 
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Afin  de  generer  1* ensemble  des  variables  emiseB  et  recues  dans  les  equipements  des  chalnes 
1  et  2,  il  a  ete  necessaire,  a  partir  du  t'iehier  standard  8  caracteres,  d'eclater  les  variables 
pouvant  ettre  entisea  par  deux  equipements  symetriques  (voir  schemas  ci-dessous). 


CHEMlNEMEWT  NON  SECURJSE 

AVAMT  ECLAT£mENT 


APRES  ECIATEmEMT 


NOTA  lA  VARIABLE  *0  NE  SERT  Oo'a  SlMUi-ER  LA  CEST1QN  DCs 
E CHANGES  DANS  SOM  R0*.r  D’AIC»J!»_l A&T  DES  variables 
EM1SES  ALTERMATlVEyEMT  PAR  Al  ET  A2 


CHEU1NEMENT  secupise 


ARRES  EClATEMEMT 


Definitions  : 


Tests  unitaires  :  tests  portant  sur  les  variables  d' Entrees/Sorties  d'un  module  unique 
Tests  manuels  :  tests  pour  lesquels  les  valeurs  des  variables  d'Entrees  doivent  etre  modifiees 
manuellement  par  le  specificateur . 

Le  deroulement  de  ce  type  de  test  est  le  sulvant  : 


1)  Constitution  d'une  chalne 

2)  Entrep  des  valeurs  d  la  CVE 

3)  Declenchement  d'un  pas  de  simulation  et  lecture  des  resultats 
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I  -  Constitution  d'une  chain* 


Cette  operation  conslste  4  selectionner  un  certain  nombre  de  variables  parmi  lc  total  des 
variables  d’E/S  d'un  module  donne  et  h  Its  regrouper  dans  un  ensemble  appele  chatne.  Sulvant  la 
taille  de  ce  module  ce  choix  a  ete  fait  : 

Pour  les  mcdules  de  taille  lmportante 

En  selectlonnant  toutes  les  variables  d ' Entrees/Sorties  se  rapportant  a  une  entite  donnee. 
Pour  les  modules  de  taille  redulte 


La  taille  des  sous-modul.es  de  ces  specifications  permet  d ’utilizer  toutes  les  variables  de 
ces  sous-modulea  pour  constituer  les  chatnes.  Chaque  chatne  est  1 'image  d'un  sous-module . 

Cette  mAthode  permet  : 

-  de  retrouver  chaque  variable  de  sortie  du  module  dai'S  une  chatne 

-  de  disposer  dans  chaque  chalne  de  toutes  les  Informations  utilisees  pour  elaborer  les 
variables  emises  par  le  sous-module. 

On  peut  ainsl  se  rapprocher  de  la  demarche  visant  a  valider  les  pieces  de  specification  de 
niveau  le  plus  bas  avant  de  passer  au  niveau  superieur. 

2  -  Entree  des  valeurs  a  la  CVE 

Cette  operation  est  reallsee  en  designant  la  variable  a  modifier  dar.r  le  Jlsre  des 
variables  de  la  chatne,  en  selectlonnant  le  mode  "modification  de  valeur",  puis  en  entrant  la 
nouvelle  valeur. 

Bien  que  la  modification  manuelle  de  valeur  de  n'importe  quel  type  de  variable  soit 
possible,  la  plupart  dec  tests  ont  porte  sur  des  modifications  de  variables  booleens  VRAI/FAUX, 
et  de  variables  loglques. 

Quelques  tests  ont  perte  sur  des  modifications  de  variables  numeriques  soit  pour  verifier 
des  loglques  (declenchement  de  seulls,  temporisations. . . } ,  soit  plus  rarement ,  pour  valider  drr. 
fonctions  de  transfert  numeriques. 

3.5  -  2eme  exploitation  maquette  -  tests  automatiques 

1  -  Interet  dee  tests  automatiques 


Z.' utilisation  des  tests  manuels  a  reveje  plusieurs  limitations  de  ces  derniers  : 

1)  Difflcultes  de  manipulation  des  chatnes  comportant  un  nombre  important  de  variables. 

2)  Inadaptetion  de  ces  tests  pour  la  recherche  de  dependances  entre  variables. 

3)  Dlfficultcs  de  validation  des  raecanismes  mettant  en  Jeu  des  transitions  ou  des 
memorisatlons. 

Ces  limitations  ont  amene  a  envisager  le  dove] rppement  de  tests  automatiques  qui 
permettralent  a  la  fois  : 

-  de  gencTer  sutomatiquement  des  combinaisons  de  valeurs  d'entree  pour  les  chatnes  a  tester 

-  de  faciliter  l'exploitatlon  des  resultats  par  des  editions  appropriees  sur  listings. 

Cenfciatlon  automatlque  de  valeurs  d'entree 

Les  objectlfs  visAs  correspondent  aux  limitations  mentionnees  plus  haut  pour 

l'exploitatlon  des  tests  manuels  : 

-  Pouvoir  balayer  toutes  les  combinaisons  des  variables  d'entree  choisles  et  observer  leur 
impact  sur  toutes  les  variables  emises  par  le  module  pour  detecter  d 'eventuelles  dependances 
anormales  entre  variables. 

-  Mettre  au  point  des  scenarios  nominoux  pertrettant  de  simuler  differences  configurations 
d 'initialisation,  des  enchatnements  de  phases  de  vol  raettant  en  Jeu  den  transitions  ou  des 
memorisatlons. 

Les  premiers  tests  ainsi  mis  en  place  appeles  tests  nono-variables  ont  permis  de  tester  toutes 
les  combinaisons  deduites  d'une  cumbinaison  inltiale  en  falsant  varler  une  variable  booleenne  de 
la  chatne. 

La  validation  des  transitions  et  memorisatlons  a  donne  lieu  e.  la  creation  du  type  de  test 
"SCENARIO  DE  PANNE".  Ce  type  de  test  permet  d'introdulre  a  des  intervalles  de  temps  traduits  en 
nombre  de  pas  de  simulation  des  Jeux  de  valeurs  d'entree  prepares  a  i'avance. 

La  verification  exhaustive  de  tous  les  css  possibles  de  valeurs  d'entree  d'une  chatne  de 
varl  blea  boolAennes  donnee  a  ete  rendue  possible  grSce  aux  tests  combinatolres. 
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En  tout  7  types  ue  tests  automatlques  ont  ete  developp£s  : 

a)  Combinatolre  statique 

b)  Conibinatoire  sequentiel 

c)  Mono-variable  statique 

d)  Mono-variable  sequentiel 

e)  Aleatoire  statique 

f)  Aleatoire  sequentiel 

g)  Scenario  de  panne 

Nota  :  Un  test  statique  se  distingue  d'un  test  sequential  par  la  remise  de  toutes  les  variables 
a  la  valeur  d* initialisation  apres  chaque  pas  de  simulation. 

Facilltcs  d'exploitatlon  des  resultats 

Pa rallelement  au  developpement  de  ces  types  de  tests,  les  possibllites  de  sortie  des 
resultats  out  ete  etendues  : 

-  Possi biiites  d* impression  ou  non  de  la  "reference"  (c 1 est-a-dlre  de  la  chalne  avec  ses  valours 
d*inltialisation) , 

-  Possibilite  d' editions  selectives  des  variables  ayant  varie  par  rapport  au  cycle  precedent. 

-  Possibilite  d' editions  selectives  des  variables  ayant  varie  par  rapport  c  la  combinaison  de 
reference. 

Ces  possibllites  o nt  permis  en  particulier  de  manipulcr  des  cbalnes  constitutes  d'un  grand 
nombre  de  variables,  sans  pour  autant  avoir  a  rechercber  les  resultats  signif icatif s  dans  ia 
liste  de  toutes  les  variables  constituant  la  chalne. 

2  -  Exploitation  des  tests  automatlques 

La  phase  d' exploitation  des  tests  automatlques  a  demarre  en  automne  85  et  a  comport/-  deux 
parties  : 

-  Tests  unitaires  automatlques 

-  Tests  globaux  automatlques 

Tests  unitalres  automatlques 

Suivant  la  nature  de  la  specification,  deux  types  de  tests  one  ete  principalc-ncrt 
utilises  : 


-  Tests  combi natoi res 

-  Scenarios  de  panne 


Pour  les  specifications  decrivant  des  mecanisir.es  de  logique  sans  memorisation  til  problemes 
d'inltialisation,  la  raajorite  des  tests  a  ete  du  type  combinatoire  statique  (specifications  de 
visualisations  notamment) . 

Pour  lcn  ?peci f ications  decrivant  un  n ombre  important  d'etats,  de  transitions  et  de 
temporisations ,  des  scenarios  de  panne  ont  ete  generalement  employes  (specification  de 
signalisation  des  informations  moteur  ou  commandes  de  vol  notamment). 

Tests  globaux 

Definition 

-  Test  global  :  test  consistant  a  activer  l'ensemble  des  modules  raaquettes. 


Nota  :  Ce  type  de  test,  dlsponiblc  /  gal  e-men t  en  mode  manuel  n'a  ete  utilise  pratiquement  qu'en 
mode  automatique. 


L'interet  des  tests  globaux  est  dc  valider  le  comportement  de  l'enscrable  des-  modules 
maquettes. 

En  effet  chaque  specification  peut  etre  v/ri.fiee  en  theorie,  a  la  seule  lecture  du 
document  de  specification  lui-metne . 

Par  contre,  il  n'existe  pas  de  document  decrivant  la  repartition  precise  des  traitements 
entre  les  dirforentes  specifications  et  esfurr.nt  ainsi  que  la  mise  bout  a  bout  des  differents 
modules  conduise  au  respect  de  la  specif ication  globale. 

3.6  -  Bilan 

1  -  Ressourcos  spcclfiques  mlses  en  oeuvre 

L'analyse  des  specifications  at  leur  codage  dans  la  maquette  ont  requls  50  Homme-Mcis, 
dont  pres  de  50  X  pour  la  phase  d'enalyne  critique  des  specif  ications.  Le  developpement  de  la 
chatne  d'outils  ainsi  que  la  mise  or.  oeuvre  de  la  maquette  ont  neressitc  22  hommes-Mois. 
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Sur  le  plan  materiel,  la  maquette  a  ece  realis^e  sur  un  syst^me  informatique  GOULD  (SEL 
32/27)  dont  11  a  4t4  necessaire  d'augmenter  la  puissance  au  cours  du  developpement  en  raison  de 
la  degradation  du  temps  de  r£ponse.  II  faut  souligner  que  la  realisation  de  la  maquette  a  pu  se 
faire  dans  les  temps  impartls  grace  k  1* utilisation  de  1' experience  acquise  lore  de 
developpetnentB  anterieurs  dans  le  domalne  de  la  simulation. 

2  -  Repercussions  sur  la  methode  de  travail 

L* introduction  du  maquettage  a  modifie  la  methode  sulvie  pour  developper  le  loglclel 
avionique  RAFALE  par  rapport  aux  habitudes  des  programmes  precedents.  Cette  modification 
concerne  essentiellement  : 

-  la  declaration  au  niveau  fonctionnel  des  Interfaces  entre  modules  (y  compriB  modules  d'un  m8»e 
equipement) 

-  l'ecrlture  d'une  specification  avec  une  contralnte  de  maquettablllte 

-  la  possibilite  de  voir  "vivre"  une  specification 

Declaratlou  des  interfaces  entre  modules 


La  coherence  imposee  au  niveau  des  interfaces  par  la  saisle  de  celles-ci  sur  1' outil  de 
base  d£  donnees  (premiere  etspe  du  maquettage)  a  indult  une  plus  grande  rlgueur  dans  le  dialogue 
entre  specif Icateurs .  En  effet  l'obligation  de  rentrer  chaque  Interface  dans  une  reference 
unique  et  regroupant  1* ensemble  des  interfaces  a  £vlte  la  plupart  des  redondances 
d* informations  (ou  leg  origlnes  d ’informations  inconnues)  que  la  dispersion  des  Interfaces 
auralt  risque  d'entralner. 

Ecrlture  des  specifications  avec  une  contralnte  de  maquettabilite  : 

La  necessite  de  decrire  des  traltements  pouvant  etre  transcrits  sans  ambigulte  en  code 
executable  (en  l'occurrence  FORTRAN)  a  permis  d'eviter  des  retards  dus  aux  difficulty 
rencontrteo  par  les  cooperants  dans  la  lecture  de  specifications  detalllees  trop  "generales". 

PosBlbilite  de  voir  vivre  une  specification 

Lors  d'application  de  fiches  de  oodif ications,  la  possibilite  de  valider  presque 
iramediatement  celles-ci  a  permis  de  "resserrer”  le  lien  entre  le  specif icateur  et  son  produit. 
En  effet,  bien  qu'il  soit  pratiquement  toujours  possible  de  tester  une  modification  (ou  un 
mccanisme  de  fa;on  genArale)  mentalement  ou  sur  le  papier,  l'utilisation  d'un  outil 
accompllssant  lui-meme  l'effort  necessaire  a  1* execution  de  la  fonctlon  de  transfert  a  decharge 
d’autant  lc  specif icateur,  lui  permettant  ainsi  de  se  consacrer  a  1 ' interpretation  des 
resultats. 

Par  contre  le  bilan  de  1 'operation  maquettage  fait  apparaltre  des  contraintes  ayant  limite 
1'lntdrSt  de  celle-ci,  fn  ce  qui  concerne  le  programme  RAFALE.  Cee  contraintes  sont  de  deux 
types  : 

-  trgonomle  de  la  maquette 

-  Dclaie  et  dlsponlblllte  des  utlllsateurs 

Ergonomie  de  la  maquette 

Malgre  les  efforts  importants  d ’ amenagement  du  conversatlonnel  de  la  maquette,  la 
presentation  tres  desincarnee  des  informations  a  rapidement  mod ere  1 'empresseoent  des 
utlllsateurs  pour  ce  nouvel  outil.  Il  est  en  effet  difficile  de  valider  le  comportement  d'un 
ensemble  de  reticules  (a  plus  forte  raison  d'une  page  complete  de  reticules),  a  l'alde  de 
VRA1/FAUX  ou  de  variables  loglques  codees.  Cette  presentation  quelque  peu  r^barbative  n'a  pas 
permis  d'explolter  completement  les  possibility  pourtant  importantes  de  la  maquette. 

Delais  et  dlsponlbllit^a  des  utlllsateurs 

Les  p£riodes  de  dlsponlblllte  des  utlllsateurs  de  la  maquette  n'ont  pas  toujours  coincide 
avec  les  periodes  ou  il  auralt  ete  le  plus  profitable  d'explolter  celle-ci.  En  partlculler  les 
tests  globaux,  interet  majeur  de  la  maquette,  n'ont  pas  eu  1' importance  qu'ils  auralent  dfl  avoir, 
en  raison  de  1 'exploitation  tardive  de  ceux-ci. 

3  -  Repercussion  sur  la  quality  du  loglclel  avionique 

L’analyse  de  l'lmpact  du  maquettage  sur  la  quality  du  loglclel  fournl  aux  bancs  d' integration 
eat  rendue  difficile  pour  lea  deux  raisons  sulvantes  : 

-  Le  maquettage  eat  l'une  des  composantes  de  la  methods  de  travail,  au  niveau  des  specifications 
fonctionnel les  d£talll£es  ;  le  resultat  obtenu  est  done  Inherent  a  1' ensemble  de  la  methode, 
l’lmpact  purement  maquette  etant  quasiment  impossible  a  extraire. 

-  La  nouveaut£  des  fonctions  assureee  par  le  loglclel.  Is  nouveauti  de  1 'architecture  et  le 
caractere  d' avion  d6moustrateur  font  du  Systime  Avionique  RAFALE  un  cas  partlculler,  rendant 
toute  comparalson  delicate  par  rapport  aux  systemes  precedents. 
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Neanmoins,  1 'analyse  des  erreurs  rencontreea  a  I'etape  d  'Integration  (verification  du  ayatkme 
permet  de  mettre  en  evidence  un  Impact  majeur  du  maquettage  : 

A  nombre  donn4  d'erreurs,  la  part  due  aux  erreura  de  specification  cat  tomb&e  de  2/3  (pour  lea 
systemes  precedents),  a  1/3  dans  le  cas  du  RAFALE. 

4  -  APPLICATION  AU  2000  NC 

4.1  -  Contexte  2000  KC 


Ce  contexte  est  sensiblement  different  de  celui  du  RAFALE  A  tant  sur  le  plan  des 
caractdristlques  du  systAme  avlonique  que  sur  le  plan  methodologle . 

-  Le  systeme  avlonique  2000  NC  represente  une  evolution  des  systemes  avioniques  K2000  par  un 
changement  de  1 'interface  homme-machine  aux  r.iveaux  materiel  et  fonctlonnel  (systematisation  des 
ecrans  de  visualisation  multiplexes). 

Par  contre  les  quelques  40  functions  operationnellcs  support4es  par  le  systeme  (particulierement 
les  conduites  de  trl)  sent  les  memes  que  celle  du  M2000  classique. 

-  Les  "plus*1  methodologlques  2000  NC 

.  au  niveau  de  1’ analyse  fonctionnelle 

Elle  a  ete  realisee  grace  a  un  outil  d'aide  a  la  conception  (OCS)  qui  permet  de  supporter  la 
decomposition  hierarchique  et  d’assurer  la  collection  coherente  des  interfaces  f onctionnellcs 
entre  modules. 

.  au  niveau  de  la  specification  fonctionnelle  detaillee 

a)  les  documents  ont  ete  ecrits  pui9  geres  en  configuration  grSce  a  un  outil  permettant  : 

.  la  composition  (textuelle  et  graphlque)  standard  des  documents 
.  une  gestion  centrallsee  de  1* ensemble  de  la  documentation 

,  une  edition  de  fiche  de  modification  et  une  remise  a  jour  instantanee  autoraatique  de 
tous  les  documents. 

b)  Chaque  document  a  ete  redige  en  equipe  int4gree,  e'est-a-dire  que  les  cooperants  ont 
participe  (sous  responsabilite  de  l'avionneur)  a  I'ecriture  des  specifications  les 
concernar.t  di rectement ,  avec  les  consequences  suivantes  : 

.  La  presence  de9  cooperants  dans  1 'equipe  de  specification  permet  d'eviter  de  specifier  des 
fonctions  non  realisables. 

.  De  plus,  les  cooperants,  dans  un  souci  de  sauvegarde  de  leur  savoir-faire  poussent  a  une 
specification  en  termes  de  besoin  et  non  en  termes  de  solution  inf ormatique ,  ce  qui 

conduit  a  la  recherche  d'un  compromis,  qui  a  atteint  sur  le  programme  2000  NC  par  les 

decisions  suivantes  : 

*  les  specifications  seront  autant  que  possible  ecrites  en  "bon  franqais"  afin  de  rester 

llsibles  et  de  permettre  leur  comprehension  global e  per  le  realisateur,  qui  sera  ainsi 
en  mesure  d’apperter  une  certaine  "expertise"  lors  de  la  realisation.  De  plus,  une 

fonctlon  donn4e  peuvant  souvent  §tre  decrite  comme  un  traitement  gen4rique  s'appliquar.t 
sur  toute  une  collection  de  donnees  diverses,  on  s'efforcera  dans  les  SDF  de  separer 
physiquement  les  traitements  (Mecanismes)  des  donnees  qu'elLes  manlpulent.  Cette  manierc 
de  proceder  permet  d'ameliorer  encore  la  lislbilitc,  l out  en  assurant  la  completude  : 
1' analyse  necessaire  pour  bien  separer  traitement  et  donnees  amene  en  effet  ur. 

recenseraent  complet  de  celles-ci. 

*  les  interfaces  des  "paves"  devront  etre  completeraent  repertories,  afin  de  permettre  la 
"visibilite"  du  logiciel.  Par  contre,  la  nature  "inf ormatique"  de  celles-ci  est  prise-  en 
compte  en  dehors  des  SDF. 

4.2  -  Decisions  et  objectifs  du  maquettage 

Compte  tenu  du  contexte  MIRAGE  2000  NC,  un  maquettage  global  n’a  pas  ete  envisage  pour  des 
raisons  evidences  de  redondance,  une  grande  partie  des  modules  Fonctionnels  etant  "recuperes"  du 
developpement  precedent. 

Le  maquettage  a  done  porte  sur  les  modules  fonctionnels  reiatits  aux  fonctions  de  dialogue 
homme -machine,  facilement  identifiables  au  niveau  de  1' architecture  fonctionnelle  et  representant 
des  traitements  entierement  nouveaux,  sclent  : 

.  le  module  "affectation  des  commandes"  : 

Cette  fonction  aiguille  les  diverses  commandes  vers  lea  fonctions  utilisatrices ,  en  ter.art 
compte  des  cholx  du  pllote  et  de  l'4tat  du  systeme. 

.  le  module  "affectation  des  visualisations" 


L 


Cette  fonction  cholsit  les  visualisations  presentees  sur  les  divers  ecrans  dt  la  cabine,  en 
tenant  compte  des  choix  du  pllote  et  de  divers  crlteres  operationnels . 
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.  le  nodule  "activation  des  functions11 

Cette  fonction  choisit  Its  fonctlons  a  activer,  en  tenant  compte  des  demandes  du  pilote  tt  de 
crit&rea  d'exclusion  mutuelle  des  fonctlons. 

L'objectif  etant  de  verifier  que  dans  toua  leg  cas  op4ratlonnels  envlsageables,  lee  fonctlons 
correspondant  aux  besoins  de  la  mission  seraient  activ4es,  qu'elles  reccvralent  correcteaent  lea 
conaandes  pilotes  et  que  les  visualisations  leur  seraient  af fectees  cnnform4ment  aux  besoins. 

Le  processus  de  maquettage  a  4t4  d4clenchd  en  Janvier  87  pour  itre  *.ermine  fin  Avril,  soit 
suffisamment  tot  pour  que  les  eventuellea  erreurs  de  specifications  pulssent  etre  corrlgfea 
avant  la  fourniture  du  premier  logiclel  r4el . 

4.3  -  Analyse  critique  des  specifications 

A  ete  soumis  a  1' analyse  critique  un  ensemble  constitue  par  les  SOF  des  trols  fonctlons  a 
maquetter,  soit  environ  500  pages  de  specification.  Y  a  ete  adjoint  un  document  decrlvant  les 
sp4clficltes  de  la  maquette,  en  effet,  lea  SDF  fournlea  decrlvaient  la  premiere  livralson  du 
logiclel*  livralson  qul  ne  dlspoaalt  pas  de  toutea  les  fonctlons  possibles  ;  en  consequence,  le 
document  de  sp4cificites  decrivait  le  traitement  a  realiser  pour  les  fonctlons  non  integreea 
dans  la  premiere  livralson.  On  notera  toutefola  que  ce  document  se  limitait  a  la  description  de 
tables  de  donnees,  les  mecanismes  des  traltementa  ayant  ete  decrlts  dans  les  SDF  et  ne  devant 
pas  etre  affectes  par  l*introduction  de  nouvelles  fonctlons. 

L*4tape  d 'analyse  critique  a  ete  aussi  fructueuse  que  dans  le  cas  du  RAFALE  A  mals  beaucoup  plus 
rapide.  En  effet,  I'utlllsatlon  systematlque  du  traitement  de  texte  pour  l'ecriture  des  SDF, 
l'equipe  intcgr4e  et  1 'attention  toute  particuliere  apportee  a  la  coherence  des  interfaces  ont 
permis  de  limiter  1* importance  du  travail  de  relecture. 

De  plus,  l'experience  a  ete  mieux  ressentie  par  les  specifications  pour  les  raisons  suivantes  : 

*  Le  principe  meme  de  l'equipe  integree  suppose  que  les  specifications  soient  ecrites  en 
collaboration,  avec  lecture  croisee  et  critique  pendant  l'ecriture. 

*  Les  specificateurs  concerncs  avaient  beneficie  de  l'experience  RAFALE  et  etaient  intimement 
convaincus  de  la  necesslte  de  specifications  completes,  coherentes. 

4.4  -  Realisation  de  la  maquette 

Idem  RAFALE  A. 

4.5  -  Exploitation  maquette 

La  procedure  utili6ee  pour  le  RAFALE  A  a  ete  amenagee  de  la  facon  suivante  pour  limiter  lc 
temps  "vol4"  aux  specificateurs. 

1)  Prise  de  contact  avec  la  maquette  ct  test  manuel  de  quelques  cas  dans  les  3  paves  maquettes 

2)  Ecriture  de  scenarios  de  pannes  pour  tester  les  mecanismes  du  pave  d 'affectation  des 
visualisations  de  manlere  aussi  complete  que  possible.  Ce  pave  est  en  effet,  du  fait  des 
imperatifa  operatlonnels  qu'il  doit  satisfaire,  une  collection  de  cas  particulars ,  dont 
1 'interaction  pouvaic  poser  probleme. 

3)  Test  global  des  mdcanlsmes  de  l' ensemble  dee  paves  maquettes.  Simul tenement ,  un  ensemble  de 
tests  automatiques  etait  lance  pour  valider  completement  les  tables  de  valeurs  utilisces. 

Cette  procedure  a  et4  Justifiee  par  les  idees  suivantes  : 

1)  Le  teBt  manuel  etant  tres  lourd  en  charge  de  travail,  il  ne  doit  normalement  pas  etre  utilise. 

2)  Si  un  traitement  est  d4crit  sous  la  forme  d’un  mecaniame  agissant  sur  une  table  de  donnees,  ce 
qul  etait  souvent  le  cas,  et  si  ce  traitement  n'est  pas  satisfaisant ,  deux  cas  se  presentent  : 

-  une  des  donnees  est  mal  cholsle  :  il  suffit  de  la  changer  pour  revenir  a  un  fonctionnement 
correct,  ce  qul  peut  etre  rapide. 

-  le  o4canisme  lui-meme  est  en  cause  :  11  faut  le  reanalyser  et  en  tirer  les  consequences  sur 
les  donnees  traitees,  ce  qul  est  forcement  assez  long. 

Il  est  done  judlcleux  de  valider  au  plus  tot  les  mecanismes. 

3)  L’af fectation  des  commandes  et  1 'activation  des  fonctlons  se  resument  a  des  mecanismes  tres 
simples  agissant  sur  de  nombreuscs  donnees.  Il  est  done  judlcleux  de  commencer  le  test  par 
l'affectation  des  visualisations. 

4)  Les  commandes  et  l'etat  de  selection  des  fonctlons  se  tradulsent  par  des  visualisations 
caracteristiques .  En  validant  l'affectation  des  commandes  et  l'activation  des  fonctlons  en  test 
global  avec  1 'af fectation  des  visualisations,  on  profite  de  la  mise  en  forme  effectuee  par 
celle-cl  pour  un  plus  grand  confort  d' utilisation. 
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4.6  -  Bilan 

1  -  Rassources  sp4ciflques  mlses  en  oeuvre 

L'analyse  des  specifications  et  leur  codage  dans  la  maquette  ont  requie  9  Hommes-mois 
(equipe  de  relecture  et  realisation),  dont  25  Z  pour  la  phase  d' analyse  critique  des  SDFO,  25  Z 
pour  le  codage  et  50  Z  pour  la  raise  au  point,  la  validation  et  le  sulvl  de  la  maquette. 

Le  sulvl  de  la  chaine  d'outlls  alnsl  que  la  mlse  en  oeuvre  de  la  maquette  ont  necessity  1 
hotame -tools. 

Les  taches  de  coordination  et  de  suivi  de  la  maquette  ont  necessite  1  homme-moi s . 

La  validation  des  specifications  par  les  specif icateurs  a  necessite  2  hommes-mois. 

Sur  le  plan  materiel  la  maquette  a  ete  realisee  sur  un  systeme  informatique  COULD  (SEL 
32/27).  11  faut  souligner  que  la  realisation  de  la  maquette  a  pu  ee  falre  dans  les  temps  lmpartis 
grace  a  1 'utilisation  de  1'experience  acquise  lors  des  developpements  de  la  maquette  RAFALE  A. 

2  -  Methode  de  travail 


L' introduction  du  maquettage  a  permis  de  confirmer  la  validite  de  la  methode  suivie  pour 

developper  le  systeme  avionique  MIRAGE  2000  NC.  En  particulier  : 

-  I  .a  conjonction  de  l'ecriture  des  specifications  sous  la  forme  raecaniEmes  +  tables  et  de  la 
description  des  traitements  en  bon  frangais  a  prouve  sa  valeur.  Elle  a  en  effet  permis 
d'atteindre  un  consensus  avec  les  cooperants  sur  le  niveau  de  specification  et  d'obtenir  des 
specifications  llsibles  mals  susceptibles  d'etre  reallsees  dlrectement  par  un  lnformatlclen  sans 
experience  ae roneutique . 

-  l' attention  apportee  a  la  definition  des  interfaces  entre  paves  a  nortp  ses  fruits  :  on  ne 
retrouve  pas  les  erreurs  du  RAFALE  (oublis  d'interfaces ,  interfaces  inutiles...). 

-  Enfin,  I'utiliretion  systematique  du  traltouent  de  texte  pour  l'ecriture  des  specifications,  et 
la  correction  de  ces  specifications  per  les  specif icateurs  eux-memes  a  permis  de  livrer  des 
documents  de  mellleure  quallte  dans  up  treilleur  delai. 


Far  ailleurs,  1’ equipe  integree,  er  apportant  une  vision  critique  dans  l'ecriture  des 
specifications,  a  permis  d'eviter  un  certain  nombre  d' erreurs,  ce  qul  a  pu  etre  constate  au 
maquettage  (pas  de  specification  irrealisable  sur  le  plan  informatique) . 


3  -  Repercussion  sur  la  quallte  du  logiciel 

Un  des  objectif6  majeurs  du  maquettage  etant  de  s'assurcr  a  priori  de  l'adequation  des 
specifications  relatives  a  1 'interface  homme/oachi re  &  tcutes  les  fonctions  operationnel les  dont 
seralt  a  terme  dete  le  systeme,  il  convient  d'attendre  la  qualification  du  dernier  standard 
systeme  pour  etablir  un  bilan  definitif. 


Neanmoins,  nous  avor.s  ru  noter  a  ce  Jour  : 

-  une  confirmation  de  la  reduction  des  erreurs  de  sped f ication  decou'fertcs  en  phase  d ' integration 
(mol ns  d'un  tiers  des  erreurs  decouverter.) . 

-  la  stabili te  de  la  specification  obtenue  (et  done  1 'evolutivite  du  systeme  realist)  : 
l'adjonction  continue  des  fonctions  nouvelles,  standard  par  standard  n'a  conduit  a  ce  lot.r 
aucune  modification  des  mecanisraes  maquettes. 


5  -  CONCLUSIONS  ET  EHSE1GNEMEWTS  DU  MAQUETTAGF  PF.  Srr.CIFICATlONS  FONCTIONNKLLES  DETAI LLEES 
5.1  -  Ce  que  le  maquettage  permet 

a )  Arae 1 i ora t i on_d  e  s_s£e  cifications 
ContrSle  de  forme 


La  relecture  critique  permet  de  corriger  et  de  completer  la  specification,  tour  l'amener  a 
wr  riveau  de  quallte  autorlsant  son  codage  direct  par  des  Inf ormaticiens  (equivalent  manuel  des 
futures  specifications  formelles  ou 1 ' outil  se  charge  de  la  telccture  et  permet  une 
compilation) . 

Le  maquettage  agit  a  ce  niveau  comme  un  puissant  revelateur  d'erreur s  ct  un  controle 
quallte  efflcace. 

L'outil  maquette  permet  une  reelle  validation  fonctionnelle  de  la  specification  au  niveau 
module,  equipement  ou  systeme  :  validation  horizontale  (tests  exhaustlfs  d'un  module)  ou 
verticale  (test  d'une  chaine  fonctionnelle  donnee).  * 

b)  Ceneration_de  J^e£x_de  ttst  o"  d ' piemen t^s_d£  rec ette 

Les  tests  statiques  et  dynamiques  realises  pendart  la  phase  de  naquettage  sent 
rcutilisables  des  les  etapes  de  verification  (branche  remontante  du  V). 


8-17 


A  ticre  experimental  dans  le  cadre  du  RAFALE  A  et  de  faqon  plus  systematique  dans  le  cadre 
du  2000  NC,  ces  teste  crt  Ste  utilises  comme  aide  a  la  olse  au  point  des  equipement s  (fourniture 
aux  coop^rants).  De  plu6,  ils  ont  servi  de  base  a  la  prevalidation  fonctionnelle  des 
equipements,  an  aaont  de  I'd tape  d'intdgration. 

En  effet,  la  maquette  etait  representative  de  l'archltecture  du  systeme  reel,  elle  pemet 
de  generer  des  jeux  d'essals  fonctlonnels  (comblnalsons  d 'entrees/sorties)  au  niveau  ddslrd 
(module,  equipement  ou  system*). 

c)  Disposition  df  une  reference  f^onc^tionne^lle^  ^aiidee 

Une  fols  validee,  la  maquette  est  entretenue  de  toutes  les  modifications  apportees  au 
systeme  et  reste  done  une  reference  a  laquelle  on  peut  se  reporter.  II  est  alors  possible  de 
l'utlliser  (ecus  reserve  d'une  ergonomie  suffisante)  comme  une  "documentation  vlvante"  et 
representative  du  systeme,  portable  et  ne  necessitant  pas  de  materiel  sp£clflque~|  ce  a  des  fine 
pedagogiques,  didactiques  ou  trivialement  pour  analyse  et  contrSle  de  cas  de  fonctionnement  non 
nominaux  du  systeme. 

d)  Support^  de_tes£  fa_p  ri  or  i_' '_d  es_e  vof ut  io  n£ 

La  qualite  des  specifications  autorise  l'analyse  et  le  chol-x  des  evolutions ,  directement 
en  terme  de  solution,  permettant  ainsi  une  connaissance  a  prion  de  icur  impact  sur  le  loglciel. 

La  maquette  elle-meme  peut  servir  de  banc  d'essai  pour  tester  f onctionnellement  les-dltes 
evolutions  et  g'assurer  de  leur  adequation  aux  be6oins  avant  leur  mise  en  chantier.  F.nfir.,  1- 
correspondar _e  document  uc  apicicicat ion/module  de  log'cie^  permet  de  prdvoir  et  de  planlfier  la 
recuperation  de  loglciel.  bile  permet  en  outre,  apres  analyse,  de  disposer  de  g^barits  en 
matters  de  volume  de  loglciel,  de  charge  calcul,...  ou  mem.  cout. 

e )  E  f  £  i  c  a  £ i  t e_jd  e  _1  ^specification 

La  consequence  directe  du  maquettage  est  de  disposer  de  specifications  autonomes  et 
auto-suf fisantes  pour  realiser  et  tester  le  loglciel,  module  par  module  ou  equipement  par 
equipement . 

Pour  des  systemes  tres  decentralises  de  type  RAFALE,  ceci  permet  de  fournir  a  chacun  des 
intervenants  les  elements  precis,  necessaires  et  suffisante  h  la  tSche  qu’il  doit  conduire.  Ce 
point,  qui  concourt  a  la  simpliclte  et  a  la  clarte  des  documents,  permet  egalcnent  une  bonne 
protection  des  informations  conf identifies . 

f )  Ane  1  iojrafl pn_dp  l_a_qpaf ipe _dp  j>roduit  final_ 

Outre  le  gain  de  qualite  obtenu  pour  l'etape  de  specification  fonctionnelle  detaillee, 
Sexploitation  de  la  maquette,  particulierement  1  *  utilisation  des  tests  automatiques ,  permet  et 
a  permis  d'amellorer  la  conf lance  dans  le  produir  final.  En  effet  des  centaines  de  tests  ont  ete 
realises  relativeroent  a  des  configurations  avion  non  nominales,  permettant  ainsi  de  deiouvrir 
(et  de  remedier)  a  des  situations  non  prevues  a  priori  dans  la  specification.  De  meme  la 
recherche  d'un  profil  de  pannes  donne,  par  balayage  combinotoire  systematique  de  toutes  les 
entrees  a  permis  de  conforter  les  analyses  de  panne  et  les  solutions  choisies. 

5.2  -  Ce  que  le  maquettage  implique 

a)  f ne  £estion  j- 1 jgou  re  us  e_et  ou£ifl£e_des_interface£  O8000jdans  pe_cas_du  RAEALEf 

La  collection  des  interfaces  entre  nodules  et  entre  equipements  represente  le  c^eur  de  la 
"machine"  ;  e’est  a  partir  de  ces  donnees  que  vont  etre  creees  automatiquement  les  variables  logi- 
cielles  de  la  maquette,  lesquelles  pourront  etre  r.timulees  et  scrutees  en  phase  de  validation. 

II  faut  done  disposer,  avant  de  comme^cer  le  maquettage,  d'une  description  complete  et  co hi - 
rente  de  ces  interfaces,  ce  qui  demande,  *  une  extreme  rigueur,  un  gros  travail  de  synthese  et 

ue  rapprochement . 

Cette  base  de  donnee  a  ete  rournie  directement  par  l'outil  support  de  l'analyse  fonctionnelle. 

b)  £ne  description  £r£cf_8£  et_c  ompl ete_  detj  poncfl^nj?  £e_transfert 

Pour  les  modules  que  I'on  desire  valider,  la  realisation  du  loglciel  maquette  corresportdant 
consiste  a  dccrire  par  du  code  executable  (manuellement  dans  le  cadre  du  RAFALE)  les  fonctions  de 
transfert  extraites  du  document  de  specification.  II  est  done  indispensable  que  cette  description 
soit  suffisamment  fine  pour  pouvoir  exprimer  chaque  sortie  du  module  selon  une  corobinaison  mathe- 
matique  des  entrees  ;  dans  le  cas  ou  la  description  est  trop  g6nerale,  il  y  a  valeur  ajoutee  entre 
la  specification  et  la  maquette,  ce  qui  est  contraire  au  princlpe  de  validation  des  specifications. 

A  noter  que  dans  le  cas  du  2000  NC,  la  forme  des  specifications  (mecanismes  +  tables  de 
constat)  a  grandement  facilite  leur  analyse. 

c)  Vne  pest ion  de_la  documentation  la_conf: l&u£*tlon 

L'aboadance  et  la  variete  de  la  documentation,  la  necessite  de  sa  remise  a  Jour 
systematique  (toute  evolution  ne  peut  etre  decrlte  que  par  modification  coherence  et  Immediate 
de  la  documentation  concernee),  exigent  un  support  de  documentation  souple  et  efficace. 
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Le  paralleliame  indispensable  entre  les  etats  de  definition  : 

-  documentation  (a  tous  niveaux) 

-  logiciel  maquette 

-  logiciel  reel 

est  obtenu  grfice  a  une  methode  de  travail  integrant  1 'usage  d'outils  de  gestion  de  la 
documentation  et  de  la  configuration. 

5.3  -  Ce  que  le  maquettage  enseigne 

1  -  Sur  le  maquettage  lul-aeme 

a  -  _L e_ma que ag_e  n'est  £u£uii  composan£  d_ ' u_ne_  me_t_h_od_e  de_travail 

II  est  clair  qu'un  maquettage  isole  de  son  contexte  n'a  aucun  sens.  En  effet,  si  une  methode 
de  travail  appropriee  n'est  pas  utilisee  pour  l’ecriture * des  SDF,  celles-ci  ne  seront  pas 
ecrites  sous  une  forme  autorisant  leur  traduction  directe  sous  forme  inf ormatique.  11  devra 
alors  y  avoir  une  "valeur  ajoutee"  lors  de  la  realisation  de  la  maquette,  ce  qui  ne  garantit 
plus  la  quallte  des  specifications. 

b  -  Le.maquet t£g  e  £o i t_e£  r£  j>recoce 

Un  maquettage  realise  apres  que  les  SDF  alent  etc  fourrles  aux  cooperants  ne  permet  pas  de 
retirer  tous  les  benefices  attendus.  En  effet,  toute  erreur  detectee  ne  pourra  etre  corrigee 
que  par  une  procedure  de  fiches  d'evolutlon,  qui  n'est  pas  gratuite  dans  le  cas  general. 

De  plus  un  maquettage  realise  a  priori  permet  dans  les  cas  difficiles  de  tester  plusieurs 
hypotheses  afin  de  choi6ir  la  meilleure  (cf  "ur.  test  a  priori  des  evolutions"). 

c  -  Le_maquet^t£g£  doi_t__e£re_  dans_une_l£gnee  d.*  outils 

Le  maquettage  ne  necessite  une  charge  de  travail  raisonnable  que  s'il  est  lntegre  dans  ure 
lignee  d'outils  informatiques.  11  n'est  en  effet  envisageable  et  profitable  que  si  les 
interfaces  sont  definies  a  priori  a  l'aide  de  l'outil  approprie,  et  si  un  outil  de 
documentation  ad  hoc  garantit  un  strict  paral lelisme  entre  les  documents  et  le  logiciel. 

d  -  _L 'e^onomie  de_la  ma^u£t£e^doi£  etre^soi^nee 

nfin  que  le  benefice  retire  de  la  maquette  soit  maximal,  li  taut  que  les  utilisateurs  n'aienr 
a  se  preoccuper  que  de  la  validation,  et  ne  se  perdent  pas  dans  le  dialogue  avec  la  machine. 

Pour  les  future  dtveloppements  il  semble  necessaire,  rout  en  conservant  les  principes  de  la 
CVE.  qui  sont  sains,  de  deveiopper  une  interface  utilisatenr  plus  "intuitif",  permettant  de 
designer  directement  les  variables  a  l'ecran,  de  changer  leur  valeur  plus  simplement,  voire  de 
simuler  a  l'ecran  les  faces  avant  des  postes  de  commande  ou  de  visualisation  de  l'avion, 
permettant  ainsi  a  des  personnes  non  strlctement  specialistes  d'une  fonction,  mais  ayant  une 
vision  -veracionnelle,  de  tirer  egalement  benefice  de  la  maquette. 

e  -  La_r£a_lisa_tion_de_  l_a  _maque£t£  est_  orma£i£ien 

Les  maquettes  RAFALE  A  et  2000  NC  ont  ete  realisees  per  des  inf onnaticiens  sans  experience 
aeronautique  particullere ,  lssus  de  societes  de  services. 

Par  contre,  le  profil  des  "maquetteurs"  doit  comporter  une  experience  des  metbeder  c\e 
developpement  de  logiciel  afin  de  garantir  ia  quail to  des  programmes  maquette. 

2  -  Sur  la  methode  d'ecriture  des  specifications 


La_forme  des  SDF  influe  sur  leur_quaHte 

La  maquette  a  permis  de  constater  que  la  forme  mecanismes  +  caules  utilisee  pour  les 
specifications  apporte  une  amelioration  de  la  qualite  formelle  des  SDF,  d'une  part  en  fo»\ant 
1 'auteur  a  systematiser  ses  traitements  plutSt  que  d’en  faire  une  collection  de  cas  decrits 
succeasivement ,  d'autre  part  en  fournissant  une  vision  globr.lt  des  traitements,  permettant 
ainsi  de  detecter  plus  facilement  les  "trous". 

Itoit^oji  utilise.rjm  l_a£g£g£  £ormel_d£  £P£c£f£cat£oii  ? 

L'experience  du  maquettage  du  MIRAGE  2000  NC  prouve  que  des  specifications  "en  bon  f rarer. ir " . 
completees  par  dee  tables  de  constantes  peuvent  etre  traduites  facilement  bien  que 
manuellement ,  en  langage  executable. 


Nearmoins,  de  fr.qcn  a  reduire  le  temps  de  real*  uation  des  programmes  maquette,  il  sorbje 
souhaitable  a  terme  de  mettre  en  ceuvre  un  langage  formalise  de  specification,  qui  seul 
garantira  le  maquettage  automatique.  Dars  ce  cas,  ce  langage  devra  etre  un  cotnposant  lntegre 
d'un  systeme  d'outils  gerant  egalement  les  interfaces  4  tous  les  niveaux  (fonctlonnel , 
bus 
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CONCLUSION  £T  AVENIR  DV  MAQUETTAGE 

Les  systemes  avioniques  complexes  sont  aujourd'hui  sounds  a  des  exigences  contraiguantes  en 
matiere  de  qualite  et  de  performances. 

La  prise  en  compte  et  la  realisation  des  objectiis  assignes  auy  systemes  passent  par  une 
maftrise  du  processus  de  developpement. 

Cette  maftrise  est  obtenue  par  le  respect  d'une  methodologle  rigoureuse,  reccuvrant  de  ragon 
continue  la  totalite  du  cycle  de  developpement  et  qui  est  a  la  base  de  toutes  les  actions  Qualite. 

Cette  methodologle  est  supportee  par  une  panoplie  d'outlls  constituant  l'ateller  systeme  et  les 
ateliers  loglclel. 

La  technique  de  maquettage  des  specifications  fonctionnelles  detaillees  a  vu  son  efficacite 
deraontree  au  tra  ers  des  experiences  RAFALE  A  et  2000  HC.  Elle  est  done  a  ce  jour  partie  ir.tcgrante  de 
la  mdthodologie  de  developpement  et  sera  utilisee  pour  les  futurs  programmes,  en  parciculier  RAFALE  D 
et  HERMES. 

Les  travaux  entrepris  a  ce  Jour  pour  en  tirer  le  maximum  de  benefices  sont  articulrs  selcn 
quatre  axes  : 

1)  Integrer  le  maquettage  dans  une  strategic  globale  de  simulation. 

Les  techniques  de  simulation  sent  couramment  utllisees  pendant  de  nombreuses  etapes  du 
developpement . 

-  en  phase  avant-projet  des  modeles  permettent  de  degager  les  concepts  operationnels  et  de  flyer 
des  hypotheses  realistes  pour  le  developpement. 

-  a  l'etape  de  specification  globale,  une  simulation  de  comportement  du  systeme  sort  d'aide  a  la 
conception  et  de  meyens  de  validation  des  specifications  de  besoin  operationnel . 

-  k  l'etape  de  specification  fonctionnelle ,  les  simulations  realisees  a  l'occasior.  du  maquettage 
permettent  de  vallder  l'architecture  fonctionnelle  et  les  specifications  detaillees  des 
constituants  du  systeme. 

Le  but  est  d'etablir  une  continuity  de  tous  ces  travaux  et  1 1  utilisation  de  ressources 
communes  et/ou  couplables. 

2)  Utiliser  les  prodults  issus  de  maquettage  pour  les  etapes  de  verification  dans  un  centre  de 
simulation  hybride. 

Le  travail  consiste  a  completer  Je  maquettage  fonctionnel  pour  le  rendre  capable  de 
s' interfacer  avec  les  equipements  reels,  done  de  simuler  le  comportement  physique  et  dynamique  des 
dits  equipements  .  Ceci  permettra  une  verification  pragmatioue  du  systeme,  chaque  equi pement 
recette  venant  "remplacer"  sa  maquette  correspondante  cu  sein  de  la  simulation  hybride. 

3)  Ameliorer  l'lnterface  utilisateur  de  la  maquette  en  la  couplant  a  des  simulateurs  d'interface 
homme /machine  representatifs  du  svsteme  et  cn  developpant  des  outils  de  test  plus  souples  d'emplol 
et  plus  performants. 

A)  Utiliser  des  langages  formels  pour  la  specification  fonctionnelle  detainee,  permettant  ainsl  une 
generation  automatique  du  code  maquette  par  compilation  de  la  specification. 
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avionics  system  during  system  and  subsystem  design  phases. 

The  case  study  demonstrates  setup  and  application  of  an 
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ABS:  Th*  systM  d«s1gn  and  davalopnant  of  a  prototype  takeoff  toward  Identifying  the  underlying  fundamental  technical 

performance  monitor  (TOPM)  and  its  avionics  Integration  challenges.  The  impl lest  lone  on  fault  detection  and 

Into  a  Falcon  10  Jet  aircraft  are  described.  The  design  Isolation  resulting  from  the  fact  that  digital  systems  ■ 
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greater  significance  to  cost  reaction  then  system 
performance,  and  demand  that  attention  be  given  to 

UTTL:  Design  and  test  of  Integrated  sensors,  avionics,  and  softwa'e  reliability.  Future  hardware  will  consist  of  a 

f 1 fght  controls  -  Experiences  In  developing  an  mixture  of  LRUs  and  LRMs.  LRM-based  subsystems  are  likely 
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ABS:  Modular  etandardlzat ion  which  has  already  been  adopted  preserving  the  Inertial  reference  system's  integrity. 

within  avionic  systems  can  also  be  used  to  optimize  the  Attention  Is  given  to  the  navigation  filter  algorithms 
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with  meeting  needs  of  the  user  faced  with  a  growing  threat.  With  the  growing  complexity  of 
avoinics  systems  (as  well  as  other  systems),  it  is  important  to  develop  and  maintain  expertise  in 
system  planning,  architecture  and  management. 

This  Lecture  Series  addresses  the  important  systems  engineering  aspects  of  Requirements,  System 
Integration,  Prototyping,  and  Design.  In  addition,  the  impact  of  technology  on  system 
architecture  will  be  discussed.  Methodologies  will  be  described  and  actual  case  histories  will  serve 
as  practical  examples  of  modem  system  engineering. 


This  Lecture  Series,  sponsored  by  the  Avionics  Panel  of  AGARD,  has  been  implemented  by  the 
Consultant  and  Exchange  Programme. 
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